-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cross-currency payment methods to NWC. #1353
base: master
Are you sure you want to change the base?
Conversation
This will help serve use cases like e-cash wallets, bolt-12 offers which allow for other currency denominations, and [LUD-21](lnurl/luds#251 wallet providers like UMA VASPs.
I don't know about the details but this seems like a good idea. |
I think it will be very helpful if you could add the explanation of wallets having an exchange rate source and possibly the option to buy sats atomically with sending to fully benefit from these new methods. |
I greatly admire the linux application development principle of "make libraries that do one thing and do it well" Frontend devs can stitch together different libraries to make creative wallet interfaces with a variety of features so if a dev wants to make a wallet that stores money in currencies other than bitcoin, and denominates money sent/received in currencies other than bitcoin, I would not advise them to use NWC, which -- to me -- is and should be bitcoin only instead, I would advise sending and receiving bitcoin only via NWC, and then do the conversion into another asset after the bitcoin has been received. And for display, I would recommend adding price conversion libraries separately from NWC and then use them to convert the satoshi amounts sent/received to whatever currency the user wants to see I would prefer if there are separate libraries for the currency conversion so that it is not baked into NWC That said, the nice thing about nostr is no one is in charge If you like this spec, just do it! And don't give a whit for my preferences when yours are just as valid |
Fair enough points! Copying over our conversation from the NWC discord for visibility: ====================================================== @jklein24: Fair enough! FWIW, this protocol can't easily be one only on one side as you describe because it needs to involve communicating exchange rates fees, etc. between counterparties. See LUD-21 for one example underlying protocol: lnurl/luds#251 @supertestnet: it seems to me that no negotiation is needed. Suppose the recipient uses an exchange rate of 1 usd = 356 sats. If he sets up a website where someone can create an invoice for $5, that invoice will be for 1780 sats. Perhaps, due to different exchange rates, the sender's wallet tells them that's $4.75. Or $5.25. Whatever. No negotiation is needed by the wallets; if the sender doesn't like that price, they can simply choose not to pay it @jklein24: The issue is if I'm paying for a good in a foreign currency. If I have sats, and I want to ensure that someone receives exactly $5, I need to know their provider's exchange rate. Similarly, it's useful to actually be able to know how much the receiver will receive if I'm sending someone money in a remmittence. In fact, my wallet (and even NWC app) may not know anything about the receiving currency, but it can still properly display it, show conversion, etc. Sure, you could build a custom app for one currency or another, but it doesn't really scale to solve the broad problem. @supertestnet: that is an excellent point; I recommend we copy-paste our discussion from here into the github discussion so that others can benefit from seeing my points answered so well ====================================================== FWIW, we're doing what you suggested and have just started using this proposal :-). If we come up with improvements in review, of course we'll adjust things on our end too. |
This will help serve use cases like e-cash wallets, bolt-12 offers which allow for other currency denominations, and LUD-21-compatible wallet providers like UMA VASPs.
Note to reviewers: I'm happy to break this out to another NIP if folks think that's better.