-
Notifications
You must be signed in to change notification settings - Fork 194
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
feat: implement stablesats for galoy connector #2730 #3020
Conversation
@openoms May I ask you for a quick review? I am also planning to test / review it during the next few days. |
Thank you for the submission @riccardobl The wallet choice on the connector screen looks good and is working, I got my Stablesats balance display correctly. There are two main things would need to be changed to deal with Stablesats correctly: The amount of the transactions need to be displayed in USD as the main unit because with Stablesats the USD value is stable and the sats number is not (~$0.01 suggest the other way around). Going next to the receive screen the See the examples of these distinctions in the Blink wallet app or here: https://dev.blink.sv/api/usd-ln-receive#generate-a-stablesats-invoice |
@openoms To address the points as requested, this PR needs to change several things in the alby core, i've already prepared a draft commit that implements these changes 4e5d52d , I'd like a feedback from the Alby team, @reneaaron, regarding the overall concept of these changes, if we reach a consensus, I'll refine the commit to align with the code quality of the repository. These are the screenshot after the last commit: |
4e5d52d
to
95291ac
Compare
I've cleaned and refactored the proposal with the goal of reducing the number of changes required to the Alby code. The points that are touched outside of the galoy connector are:
I've forced pushed the refactored commit to the pr branch: 95291ac |
The history, balance and the invoice is now correctly denominated in USD, all working well. The Stablesats implementation is complete from my point of view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much for this PR! 🙌
While providing a first-class USD experience for users is a great goal to strive for, it poses quite some problems that might not seem obvious in the first place and add a lot of complexity:
The concept of sats is deeply embedded in the wallet and outside APIs (such as WebLN). Changing e.g. the receive screen to use USD as the primary currency will only work for when a user creates an invoice manually, however it will break contracts with WebLN as these APIs only knows sats and no fiat currencies. (see webln.makeInvoice() for instance)
I wonder how we should deal with this problem 🤔 Possibly you could also add an API on Galoy side that allows to create USD invoices by using sats as the unit? (and convert it internally using the current exchange rate)
FYI: We are about to improve the invoice creation for fiat currencies in #2511 which would improve the experience for stablesats accounts as users would be able to enter USD amounts, too. (the converted sats amount could be submitted to the API then)
For now I would prefer to keep the changes related to different UI components (ReceiveInvoice, TransactionTable, TransactionModal, etc) to an absolute minimum. I assume users will know they connected their USD denominated wallet and I am afraid changing primary units all across the application will add quite a lot of complexity when applied to all affected parts (e.g. budgets, etc)
I think the vast majority of use cases are fine with doing the sats -> usd conversion in the galoy connector before creating the invoice, like i did in the first commit (then removed since it wasn't needed after changing the receive page with usd based input), i can revert back to this behavior and then #2511 will provide the usd input as asked by @openoms
Since there is already the concept of currencies for balances, would you be fine with keeping the change only for transactions? If the connector uses sats internally, it should be just a visual change. Would one of these two options qualify as a valid solution? |
Thank you for the review @reneaaron! Having the ability to create invoices priced in USD like discussed in #2511 could work as the main problem is the different accuracy of sats vs cents resulting in rounding on conversion and inconsistency in the amounts (noted in my first comment). #2511 (with the USD invoice creation) would become the dependency of this PR. The fixed USDcent denomination would need to be kept for the transaction history, would be happy with either of solutions offered by @riccardobl as the Alby maintainers see fit. |
7905aec
to
b7cad44
Compare
b7cad44
to
e91d466
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just did another round of testing & reviews, great progress and clean implementation so far! 👌
- The send page currently doesn't work as it's checked against the USD balance: 🤔
- webln.makeInvoice currently leads to quite strange behavior due to different rates being used for the calculation
makeInvoice(210000) led to an invoice of 209742 sats. Do you know if there is a way to use the galoy exchange rates or denominate an invoice in sats for the USD account?
You can use this page for testing:
https://webln.twentyuno.net/invoice
let amountSats = Number(args.amount); | ||
if (currency !== "BTC") { | ||
const rate = await getCurrencyRateWithCache(CURRENCIES[currency]); | ||
amountSats = this.toFiatInt(amountSats * rate, currency); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
toFiatInt() is a bit misleading here as it's converting from fiat to bitcoin, right?
Maybe fiatToSats() is better here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually transforming a float $ value to an int cents value. So maybe something like this would be better:
toFiatCents
fromFiatCents
this seems like a bug in alby not in this pr necessarily |
…d usd invoices, fix naming
It should be fixed in the last commit, i've changed the code to use lnUsdInvoiceBtcDenominatedCreateOnBehalfOfRecipient that is either a new api or i didn't noticed it before. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK
I think this is a great start! 💯 Thanks everyone involved! We're now prioritizing #2511 to improve the integration further. @riccardobl You have done a great job in here, thanks for your detailed analysis and thought-through suggestions on GitHub & Discord. Really appreciate your structured way of working! 💪 If you are up for it, we'd love to get your help on #2511 as well. |
Thank you, it was a pleasure to contribute to the project. |
Tested in the main branch now and the changes work as expected, ticking our bounty requirements which now can be considered complete: GaloyMoney/blink#3950 (reply in thread) Thank you very much for the work @riccardobl and the reviews @reneaaron! Looking forward to working together further on maintaining and improving this integration as already proposed in #2511 |
Describe the changes you have made in this PR
This is my submission for the galoy bounty GaloyMoney/blink#3950 and feature request #2730
The PR adds support for stable sats in the galoy connector.
Let me know if i missed something
Link this PR to an issue [optional]
Implements #2730
Type of change
feat
: New feature (non-breaking change which adds functionality)Screenshots of the changes [optional]
How has this been tested?
USD (Stablesats)
walletChecklist