Open antoinevw opened 2 years ago
Hi there!
We currently only support a subset of LNURL features (more specifically just lnurl-withdraw
, which allows you to scan/paste an LNURL and withdraw funds from another service). From what I read you are in need of lnurl-pay
.
Good news is that is already in our roadmap!
Thanks for your suggestion!
Glad to hear that you guys are working on implementing the LNURL support! Is there any update on the LNURL payment feature?
Hi there!
We're researching what wallets and LN services do with the protocol and designing a flow that fits the rest of the app. Sorry that it's taking so long. The protocol has lots of features and it's not easy to support everything without breaking consistency with what we already have.
If you don't mind me asking, do you have any service and/or wallet that currently use lnurl-pay and that you have had a good experience? Would you mind telling us what you like/dislike about it?
Totally understand and appreciate your guys' hard work! At the moment Muun has been our main driver for its ease of use. Other option which seem to have the lnurl-pay feature that I have, but have not tested out are Blue Wallet and Blixt.
I can tell you the real-world use case, however; it's an art gallery. I'm looking to be able to have a QR code attached to each piece of art that would allow someone to scan, generate an invoice and pay without needing to interact with another electronic device.
This site has a list of wallets with different features that they support (toward the bottom): https://coincharge.io/en/lnurl-for-lightning-wallets/
Also, maybe you're aware of another way for me to accomplish this? BTCPay Server's payment request seems to be a possible alternative. They also support LNURL though, which seems easier to implement and maintain.
I'm afraid I'm having trouble correctly picturing the use case. Would the QR codes be printed? Are we talking about a digital art gallery? Would the invoices be 1-time-only (e.g the one who pays, now owns the item) or are they use for some sort of "tipping" for the artist?
Be that as it may, we are currently only considering implementing PAYING lnurl-pay QR code/uris in Muun, not displaying them (aka using muun to receive via lnurl-pay). This is because receiving using lnurl-pay needs a 3rd party intermediary/server and that would go against self-custodianship. If that is what you are envisioning, then yes, BTCPay Server is a great choice.
yes correct, the QR codes would be printed. Like shown in the video in this link: https://blog.btcpayserver.org/btcpay-server-1-3-0/#lnurl-pay-print-point-of-sale-
Ok. I think I understand now. The options are:
If I may add, I too, use LNURL-PAY. Self-service drinks at the gym. People grab a bottle, scan a printed QR code and pay for it on the spot. I've tried, I think, almost all wallets that support LNURL-PAY and had to settle on Wallet of Satoshi due to how simple it is to use for newcomers. But it has problems. One obvious that it's custodial. And the other that it has these weird hickups where QR code that worked fine previously, stops working for some devices until a full logout and data clearing is done (very inconvenient considering that it takes 24h to reactivate the balance).
Long story short, I honestly wanted Muun as the main wallet to shill to the gym members, but was sad to see no LNURL-PAY support. Hopefully you guys can implement it sometime soon. I cannot overstate the importance of near perfect UX experience for someone who has no idea what Bitcoin and Lightning is. New tech, especially involving finances, literally scares people. But the trick that does it for them is really as simple as "show how to scan a qr code and press pay". I hope you're going to be one of those wallets that help introduce more people into Bitcoin world.
Let me know if you need more explanation on the use case.
P.S. The LNURL support comes from BTCPay Server. They have PoS system, that's really convenient.
I think there has been some confusion and it seems like Muun is indeed considering implementing the ability to read LNURL-Pay QR Codes (in order to PAY them, like you mentioned @acrespo).
So, e.g., in my use case:
I have a BTCPayServer running for a cafe and is LNURL-Pay enabled. I.e., I display a static LNURL-Pay QR code. A customer with Muun wallet scans it, causing BTCPay Server to create a lightning invoice for the Muun user who can then pay it.
Is this still under consideration?
I'm not sure what got you confused but sorry for that! I can confirm that we very much intend to support PAYING via LNURL-PAY (e.g read/scan LNRUL-PAY Qr Codes, in order to send payments). What we're thinking will play nicely with something like the BTCPayServer printed LNURL Qr codes you shared.
From what I understand this would cover @varunagym use cases and yours. Right?
@acrespo yes, indeed. Can't wait!
no worries! I don't think the confusion originated from you! It's tricky to figure out how all this stuff works. HTTP layers, Lightning protocol, BTC protocol! Soon enough it will all be abstracted away I imagine :)
Do you know the timeline of implementing the ability to PAY LNURL-PAY QR codes on Muun? Pretty much our whole community uses it.
Another use case that I for it is with being a vendor that can accept payments offline using something like the LNPoS. These leverage LNURL-PAY in a way that's great for countries where internet may not be so stable.
It requires a node connected and online somewhere, but then there can be an offline device with a link to it encoded in a QR. Let's take taxi drivers in 3rd world countries, for example. Taxi drivers could have a device that's extremely low-cost (like $20) and doesn't require internet to display a payment code to someone. The person paying (who does need to have internet connection) gets directed to the online and LNURL-PAY enabled node which serves them an invoice.
It would be a really powerful, low-cost way for people in less wealthy areas to receive bitcoin via lightning and only requires the ability to pay LNURL-PAY links!
I can't realistically share a timeline but it's definitely in the works. Getting the UX just right is proving to be quite a challenge but we'll get there. We understand it has exploded in popularity and we're excited about the use cases it enables.
PD: I'm a big fan of LNPoS! We have sometimes toyed with the idea of having more "merchant oriented" features or having a "merchant optimized" version of Muun.
Just wanna +1 for how great it'd be to have support for LNURL-Pay. I plan to use it a lot over the coming football season for Real Bedford (they use tippin.me) and will have to stick to Phoenix unless I am happy with giving up my UTXO privacy to the world by doing on-chain donations.
As muun is one great way for onboarding people LNURL pay would be great to have! I'd like to onboard sellers who could onboard their customers and they could use the QRs very well.
@acrespo Galoy has added LNURL Fallback Scheme to Bitcoin Beach Wallet's static Paycode QR - context .
Testing various Lightning Wallets, I noticed that Muun does not support LNURL-Pay yet. This is when I found this issue and delighted to read that you have LNURL-Pay support on your roadmap.
When you add LNURL-Pay, please consider correctly reading LNURL-Pay QRs that have implemented the Fallback Scheme defined in LUDS-01.
You can test here
The QR encodes the following: https://pay.bbw.sv/IDEASARELIKEFLAMES?LIGHTNING=LNURL1DP68GURN8GHJ7URP0YHXYCNH9EEHVTEWWAJKCMPDDDHX7AMW9AKXUATJD3CZ76TYV4SHXCTJV4KXJ6M9VEKXZMT9WVFEEZHA
Thank you.
Tried to buy BTC shoe lances with a merchant that uses BTCPay server. It shows it doesn't support "LNURL-PAY"
Thought wallets should be build for users to spend BTC, without worrying about the underlying mechanics.
Tried to send a lightning payment using a LNURL link, got this message in response - it tried to switch to receiving via lightning with an error message suggesting this is not allowed by the protocol.
Apparently other wallets do support this.
What is going on? Is this simply not implemented yet? I really like the interface and simplicity of this wallet, don't really want to switch to another. Thanks!