nostr-protocol
Add cross-currency payment methods to NWC.
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.
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. And then also explain how wallets that do not support exchange rates themselves should handle these requests and are still compatible with the apps just using sats. In general extra explanations on all requests and what should be done by the wallet exactly to handle them would make everything more clear.
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
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: https://github.com/lnurl/luds/pull/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.