LUD-XX: Currencies

[ethanrose]

My initial PR (Pouch.ph implementation) was #207

This new proposal is an update from my original PR, in order to be compatible with:

• Bipa implementation: LUDXX - Add proposal for currencies on payRequest #251

• LightSpark implementation: https://github.com/uma-universal-money-address/protocol/blob/main/umad-04-lnurlp-response.md

However, I have left out some of their implementation details in the spirit of keeping the spec as barebones as possible.

Namely:

• Convert/convertible: At Pouch, currency conversion is a recipient config, not a sender's payment flow decision. If some services wish to give the sender power over the recipient's settlement currency by sending a param, it should be a follow-on LUD.

• Final Response Multiplier & Fee This doesn't provide info that the wallet can't already derive (multiplier) or should trust (fee). If services are using this, it should be a follow-on LUD.

[ethanrose]

For review, if everyone could give either a 👍 or express any blocking concerns: @callebtc @trbouma @lsunsi @fiatjaf @vindard @jklein24 @lorenzolfm @Kukks @kngako (please feel free to mention others for review as well -- several others are using a variant of this spec, but I am unsure of their github handles).

[jklein24]

I don't think I agree that the stuff you're leaving out should be follow-up LUDs. They're pretty critical functionality for us at least.

[jklein24]

This is the reason that the multiplier in the payreq response is critical IMO. The way this is interpreted in UMA is that the first response includes an estimate for while the sender is typing an amount, then the second response actually locks a quote including rate and fees.

[jklein24]

This is missing critical functionality of the original LUD which allows the sender to lock either the sending or receiving amount. If I'm sending from USD to MXN, I need to be able to say either "I'm sending $100 USD" or "I need the receiver to receive $100 MXN". Both are quite important for different use cases. UMA doesn't use the full subset of flexibility for the convert stuff, but it definitely needs this point to still exist.

[lsunsi]

I haven't had the time to read the full spec yet, but I'm inclined to agree with @jklein24 comment's about the quote mechanism being core to the functionality.

The current implementation at showcased here shows that working, if you "receive as Reais R$" you'll be able to see rich information about a quote (price, fee and how much sats it'd cost) with a ever-refreshing invoice but fixed receiving amount in local currency.