LUD-XX: Currencies - #298
Conversation
Clarified the role of the SERVICE in auto-conversion and its relevance to the WALLET sender.
|
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). |
Add functionality for requesting invoices in supported currencies.
jklein24
left a comment
jklein24
left a comment
There was a problem hiding this comment.
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.
| ``` | ||
|
|
||
| - The inclusion of the `currencies` field indicates the support of this extension | ||
| - The `multiplier` may be included for informational purposes, not a guaranteed rate |
There was a problem hiding this comment.
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.
|
|
||
| ```diff | ||
| - <callback><?|&>amount=<number> | ||
| + <callback><?|&>currency=PHP&amount=<numberInSmallestUnit> |
There was a problem hiding this comment.
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.
|
I haven't had the time to read the full spec yet, but I'm inclined to agree with @jklein24 comment's about the 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. |
lorenzolfm
left a comment
lorenzolfm
left a comment
There was a problem hiding this comment.
Hey @ethanrose. Just pair reviewed the PR with @lsunsi.
|
|
||
| This document describes an extension to the [payRequest](https://github.com/lnurl/luds/blob/luds/06.md) base specification that allows the `WALLET` to send money to a `SERVICE` while denominating the amount in a different currency. The features proposed enable many use cases including: | ||
|
|
||
| - Bitcoin-settled cash remittances |
There was a problem hiding this comment.
What do you understand by "remittances"?
From what I understood from the spec, this doesn't enable a remittance UX like Wise, for instance. This would required the convertible info
| + "decimals": 2, | ||
| + "minSendable": 1, | ||
| + "maxSendable": 50000, | ||
| + "multiplier": 64501 // (optional) |
There was a problem hiding this comment.
Why do think this should be optional?
The service already knows the multiplier because its needed in order to fulfill the denomination request. So why not share it with the wallet.
|
|
||
| ```diff | ||
| - <callback><?|&>amount=<number> | ||
| + <callback><?|&>currency=PHP&amount=<numberInSmallestUnit> |
There was a problem hiding this comment.
Why did you go with currency outside instead of inside the amount, like here
Is not that we don't like this option, but we chose the other one because without it was less umbiguous in case wallet misuses the API. A service not supporting the LUD wouldn't even be able to understand the request
| + "minSendable": 1, | ||
| + "maxSendable": 50000, |
There was a problem hiding this comment.
Given that multiplier is not optional (see here), wouldn't minSendable and maxSendable be a derivation of multiplier and top level minSendable and maxSendable.
Since this LUD is just about denomitation there is no further limitation imposed by different currencies not already represented in the minSendable and maxSendable on top level
|
Just confirming that I concur with @lorenzolfm 's questions, and I have suggestion. Although I think #251 was good to go, I think slicing #251 with just the denomination functionality might be useful in order to get it merged. That said, I'd be more comfortable endorsing this approach if it was compatible with #251 so it could be PRd later with the convertibility functionality. We are quite close but not quite there and answering @lorenzolfm 's questions on the subject will get us closer.
|
4 participants
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.