search

lnurl / luds

lnurl specifications
596 stars 140 forks source link

Unified QR Code #177

Open augustresende opened 2 years ago

augustresende commented 2 years ago

Could we adapt LNURL to work with https://bitcoinqr.dev standard?

Related: https://github.com/sbddesign/bip21-site/issues/70

RajGoodF commented 1 year ago

Any update on this ?

fiatjaf commented 1 year ago

What is needed?

BitcoinErrorLog commented 1 year ago

This should probably be a PR for BIP-21 instead, to formalize extending it for more payment types. The actual work needed would be for wallets and merchants to support variable payment endpoints, as you cannot fit enough detail in a QR to include them all.

This is what Slashtags is working on with its payment (slashpay) features. The original POC is here, and we have a more elaborate implementation in Bitkit wallet.

augustresende commented 1 year ago

This should probably be a PR for BIP-21 instead, to formalize extending it for more payment types. The actual work needed would be for wallets and merchants to support variable payment endpoints, as you cannot fit enough detail in a QR to include them all.

There is a PR in BIP-21 site https://github.com/sbddesign/bip21-site/issues/70

RajGoodF commented 1 year ago

What is needed?

As we are having single qr for bitcoin onchain address and lightning invoice, can we embed the lnurl pay also with it, so we need a single qr, which have bitcoin onchain address and lnurl-pay. So that at brick-mortar stores can have multiple payments on one qr.

BitcoinErrorLog commented 1 year ago

instead of lightning= just put lnurl= and pray.

RajGoodF commented 1 year ago

I tried that, but phoneix wallet wasn't able to decode it, so not sure is this issue from my end, or the third party wallet.

BitcoinErrorLog commented 1 year ago

You misunderstand how these things work. Updating a spec does not force every wallet to update. I am only saying the simplest way to design what is being asked here. The work of getting every wallet to support it is another effort.

sbddesign commented 1 year ago

I think @BitcoinErrorLog's assessment is correct. I'll add a little more context for you, @RajGoodF.

BIP21 is a spec that's been around for a decade. Here's the spec doc. BIP21 very clearly allows you to create any parameter you want. You could add a silly param like ?potato=12345 to the end and that is a perfectly valid BIP21 URI. However, there's no guarantee that every wallet is going to add support for whatever cool feature the potato param enables. That's sort of the idea: it's meant to be flexible.

BitcoinQR.dev is not really a spec, it's just a site that talks about how you can make a unified lightning and on-chain QR code by using a lightning param in a BIP21 URI. And then it has a log of which software supports this method and some other resources. That's about it.

So absolutely, projects that use LNURL could certainly use BIP21 if they choose. But that probably means talking to wallet projects and building support for extracting a ?lnurl= param from the URI. Or perhaps putting the LNURL data inside the lightning param, and getting wallets to expect that this param might contain a BOLT11 or might contain LNURL data.

But regardless, that's really a matter of talking with wallet projects and building support for this idea. IMHO, that doesn't necessitate updates to any LUDs.

dennisreimann commented 1 year ago

Seems like Zeus, Alby and Wallet of Satoshi (at least partially) support LNURL in BIP21 via the lightning= query string parameter. https://twitter.com/ZeusLN/status/1617622048314101766

Imho it'd make sense to let the wallet figure out the details and not introduce a new param like lnurl=, because there are most likely more additions coming up and the QRs are already dense.

augustresende commented 1 year ago

@dennisreimann officializing this "standard" of accept lnurls in lightning params in the both specs (lnurl and bitcoinqr.dev) would be good. Agree @fiatjaf ?