Even 4 years ago we were called crazy for using keysend instead of LNURL but went with keysend because of its lower overhead.
I think they did, but have moved on.
I asked nostr:nprofile1qqsd4dkxqewy8xum47ctpu0ltgxxsfemeewpjkdyzk9ddfcg286s0dsppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq36amnwvaz7tmwdaehgu3wvduhq6r9wfc82mnt9e6x7erp0yhs4deh46 just this basically because I knew you had this question. "Why don't we just stay with keysend."
Two versions with chapters and transcripts. Jurajs is CD quality, mine is 1960s vinyl mono.
CD:
https://podverse.fm/episode/vXq53327n
Mono:
Discussion
The question that Juraj and I have still stands though, maybe I should ask on mastadon -- why not change the rss spec with the value Tag to have an option for other payments instead of adding lnurl.
We thought this would be backwards compatible and since apps have to fetch the rss feed anyway, better then ALSO going to the website for lnurl.
I asked on podcastindex social and tagged Dave.
This was Adam Curry’s response for those not on Mastodon.
“The lnaddreds proposal was written at the request of fountain, alby and breez, who all run infrastructure. If their nodes change, everyone's feed has to change. This abstraction subverts those problems.
It also makes the feed info future proof for Bolt12 and stuff not yet invented.”
If I understand correctly, the idea is to move to an externally hosted file that has all of your payment options. As your options change, it’s simply a matter of updating that one file. Right now, if you’re a guest on a podcast and your wallet changes, you have to ask every single podcaster to update every single value block you appear in. With the external file, you update one file and every app will now pull in the new address.
Ok so the idea is to pick lnurl so that podcast hosts have this lnurl with options. Guests, presumably have just a lnurl either from their own host or with a custodial wallet or some service that hosts the lnurlp for them.
?
I think the original idea was to call it lnaddress and just use it to fetch a static file with all of your payment options, which would include lnurl. At some point it got hitched to lnurl, and I’m not take sure why. I like the idea of having a link to a static file I control with all my payment options, which may include lnurl. Tying it to lnurl or lnurlp as an options file has line of made it more confusing and I’m not sure what the rationale for it is.
This is a very cool point and we haven't thought about it, so thank you.
Let me brainstorm about this a bit further.
My assumptions:
Keysend - not changeable directly, many client wallets don't support it.
It is better to limit the options of receivers, not so much senders.
Lnurl - needs DNS and https, good for podcast hosts (they have this already for their feed in one way or another), not so much for the guests that don't have their own podcast. Most people don't run webservers.
Most guests will give you unchangeable address anyway, like fountain address / keysend params. If they change it or if for example fountain ceases operations, it won't work.
Just putting out two other options:
- key magic. With lnproxy you can receive at some key (keysend and bolt12 and bolt11 are possible) that is not a node by itself. It's just in ln network and it will proxy the payment wherever it needs to go. Your address would then not be reliant on dns. You can not change the key, but it can be a receive key that you direct to a particular node. Needs some always on thing, but can be a third party service that provides this with fallback to running it elsewhere if you are not satisfied. You can do both custodial or non custodial.
- use Nostr. Before rolling your eyes with the thought of added complexity - from the client side, a Nostr lookup is the same REST API request as lnurl. You send a query and you get a json (which is signed for added security). You don't rely on any particular web server, you can lookup at many relays. Great for availability. You can generally store profile information on many relays that don't otherwise allow posting.
This gets away with users having to run webservers, no domains, but you can update your address any time with one signed Post request sent to many relays.
Also, fountain already has Nostr, so the users have keys, but the keys are there and are not bound to fountain forever. It is also possible to put keysend data or other payment forms in nostr profile.
(You might guess I don't like DNS much, domain cancellations are real).
So valueRecipient tag would be static, no reliance on particular domain name or webserver, user controllable, does not need to rely on server under user's control, but as long as they have the key, they are always in full control. Allows for both custodial and non custodial solutions and there's an easy upgrade path for users from custodial to sovereign.
Bonus with Nostr lookup - you can get payment info for all value recipients with one rest call, no need to contact several servers or make several requests. The nostr filter query can contain multiple pubkeys.
keysend > LNURL
the only thing LNURL has going for it is its native to the web, so I don't need a full lightning node to send a payment
Doesn’t Bolt12 pretty much eat keysend’s lunch?
maybe, but it wouldn't change much in this case, because its an app making an automated payment. so the app would still have to have access to a lightning node in some way
All of this always seems to loop back to resistance to the running of a lightning node, which seems a little gay to me 😁
There's two things here
I run a node and its been the best lightning wallet I've ever had, never fails and its a great way to store sats
But it does not work well as programmable money. there is no way to connect to it from a web app, and there is no way for a web app to easily talk to your node (to ask for an invoice)
The issue is nodes exist on their own network (for security reason) and its really difficult for transitional apps to find a reliable way to talk to them (tor sucks)
Every podcasting 2.0 app I use or I've tried just used alby as the users wallet because it was too hard to get an app to talk to a node
That said what alby is doing now with alby hub and NWC has made it possible for me to use my node as more than just a simple payment wallet
I am gonna research this more in the coming months, have some plebdev courses lined up. There's gotta be a way to do it smartly. Fountain/ZBD do it.
What hzrd149 laid out is kind of what we talked about on BWB. Nodes have always been great for receiving but not sending in a PC 2.0 aspect until AlbyHub.
For me AlbyHub is just as game changing for PC 2.0 as lightning was 4 years ago.
Does this all have to rely on AlbyHub or even keysend? idk but that’s what we have and it’s powerful.
Everyone in PC 2.0 says no listener will setup AlbyHub and run their own node, well here I am. I’m far from your average listener and have been at this for a long time but this stack solves so many problems for so many people.
Is Alby’s role in PC 2.0 in jeopardy? Only time will tell but most of PC 2.0 took Alby out back and shot it once they moved to AlbyHub.
This is all just the late night, I can’t fall back asleep and probably should be on my phone at 3am ramblings of a dude that loves podcasts and Bitcoin that wants to send it to people, help build out a little pleb lightning network and be in control of his sats. Is that too much to ask???