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

Allow paying before fee is estimated #78

Closed
bezysoftware opened this issue Mar 3, 2024 · 5 comments
Closed

Allow paying before fee is estimated #78

bezysoftware opened this issue Mar 3, 2024 · 5 comments
Assignees
Labels
😄 UX Something that helps improving the user experience 🐍 intermediate Implementation is not easy, but also not that hard.

Comments

@bezysoftware
Copy link
Contributor

Often while paying the fee estimation takes a very long time even though it ends up being 1 or even zero hops. It would be nice to set a maximum allowed fee (percentage?) and enable to pay button even while fee estimation is running. This would greatly improve experience while paying for coffee with a line of ppl behind me.

@bezysoftware bezysoftware changed the title Allow paying before fee is calculated Allow paying before fee is estimated Mar 3, 2024
@michaelWuensch
Copy link
Owner

Thanks for the input.
It is already possible to set a fee limit for lightning transactions in the settings.
From your perspective, what would be the preferred User experience?
A: Don't show a fee estimate at all and just ensure the limit.
B: Calculate the exact fee, but unable to send while it does so (current situation).
C: Calculate fee estimate that can differ from actual fee, but allows sending while calculating.

@bezysoftware
Copy link
Contributor Author

I would prefer option c). It can keep the ui as is, but enable the send button even when fee is being calculated (progress ring is spinning). Bonus would be showing the maximum possible fee calculated from settings and the invoice amount.

@michaelWuensch
Copy link
Owner

Ok, thanks.
I'll see what I can do.
After the change, expect the payment to take about as long as the fee calculation did.
The fee calculation was basically sending a payment that fails on purpose. And then using the route it found to actually do the payment. This way it is possible to calculate the fee exactly, but with the drawback of waiting longer.

@bezysoftware
Copy link
Contributor Author

Thanks. Yes that was my guess, sending a failed payment. But technically the fee is still just a guess because the route might no longer be eligible when I actually pay, right?

@michaelWuensch michaelWuensch added 🐍 intermediate Implementation is not easy, but also not that hard. 😄 UX Something that helps improving the user experience labels Mar 12, 2024
@michaelWuensch michaelWuensch self-assigned this Apr 20, 2024
@michaelWuensch
Copy link
Owner

This is done now and shipped with v0.8.0!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
😄 UX Something that helps improving the user experience 🐍 intermediate Implementation is not easy, but also not that hard.
Projects
None yet
Development

No branches or pull requests

2 participants