juraj on Nostr: This is a very cool point and we haven't thought about it, so thank you. Let me ...
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.
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.