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.
