Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

jklein24
Copy link

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.

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.
@rabble
Copy link
Collaborator

rabble commented Jul 15, 2024

I don't know about the details but this seems like a good idea.

@kumulynja
Copy link

kumulynja commented Jul 20, 2024

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.

@supertestnet
Copy link

supertestnet commented Oct 15, 2024

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

@jklein24
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants