-
Notifications
You must be signed in to change notification settings - Fork 492
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
How to handle multiple invoices in a single "lightning:" URI? #1111
Comments
There is currently no such standard. You're welcome to suggest one and work with Lightning wallets to get it supported. |
Suggestion by @TonyGiorgio is Any comments/concerns? |
This appears like pretty unique use case and something which should be handled at the app/wallet level. Not something which needs a change at the spec level. |
I wouldn't bother specifying it in the All that said, as @saubyk points out, you really should speak to wallets who would have to implement this - there's a good chance they have little interest in building out an entire UI flow just for this. |
Yep, I am talking to a couple of wallets as well. I was just hoping to get some feedback from a larger audience. Nostr users will gravitate to apps that support the new schema. So, it's fine if some apps don't want to support it.
For Would parsers understand the reuse of a param? |
This is related to this bitcoin-dev BIP21 thread about allowing or not allowing multiple same key arguments, should they be allowed or not - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021940.html. If they are, in context of unified QR codes, one could use |
BIP21 does not specify how to handle such situations, it's undefined behaviour. |
Seems to make more sense.
It feels like it's a Unified QR prescription (they have to choose how to represent AND or OR) and not much of a BIP21. How can this use case help un-undefine this behaviour? :) |
As an example, this URI
could mean:
or it could mean
|
The issue here is that there is no way to support multiple on-chain addresses in the same URI Ideally, if we are splitting payment to 3 receivers, a unified URI should include on-chain addresses and lightning invoices for each receiver. Which seems to break everything. |
Why not I'd very much like to go rewrite BIP21 to much better capture forward- and backward-compatibility of bitcoin: URIs... |
I am much in favor to keep the same standard that we use today in normal URL without reinvent a new format that required to implement a custom parser and so on.
Or from the grammar of BIP21
we can build your own grammar where the Or better like some programming languages do while supporting new syntax you can make a lightningaddress a any thought? I am missing something? |
We just saw a split with 135 ln invoices. People are truly pushing the limits :) The issue I am having now is purely semantical. BIP21 seems designed for one receiver (1 bitcoin address) with multiple options of payment lninvoice OR the on-chain address. A Nostr Split would have multiple receivers, so ideally, it would push several URIs, one for each receiver.
|
What's the URI size limit? At 135 invoices you may need to move to some kind of intent API. |
AFAIK RFCs doesn't specify any limits on URI length, but different software has different limits. |
Yeah, I think there are no limits on links, there are fancy auth links that are very long, but 135 URLs seem uggly to me, but Bha! |
How about just having bunch of BIP21, BOLT11 or BOLT12 URIs separated by newline? |
TLDR: Let's say I have 5 bolt11 invoices to be paid and I want to pass that information to a Wallet application in a single "link". How can I produce a URI that contains all five invoices?
Longer version:
Nostr allows users to set up split payments per post. Nostr apps must assemble individual LN invoices for each of the recipients and then pay them all. On mobile, each payment call becomes a
lightning:
URI to be open by the Wallet application. This means users need to go back and forth between the caller app and the paying app for as many splits as needed. It's quite annoying.A solution would be to stack all invoices in one call and allow the Wallet app to display all invoices in the same screen and have a single pay button to approve them all.
PS: It's not an all of nothing situation. If one invoice fails, it's fine. The others can proceed.
The text was updated successfully, but these errors were encountered: