How to handle multiple invoices in a single "lightning:" URI?

[vitorpamplona]

How to handle multiple invoices in a single "lightning:" URI?

[TheBlueMatt]

I wouldn't bother specifying it in the lightning: URI space, since that's increasingly being replaced with unified bitcoin: BIP 21 links. Also, URIs should be in the format namespace:path?param1=value1&param2=value2&.... I'd recommend using a short, capitalized parameter name like LNI1, LNI2, etc (for LN invoice, cause probably LN1 etc should be used for BOLT12 :) ).

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.

[kristapsk]

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.

[kristapsk]

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 became 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.

How about just having bunch of BIP21, BOLT11 or BOLT12 URIs separated by newline?

[TheBlueMatt]

There is currently no such standard. You're welcome to suggest one and work with Lightning wallets to get it supported.

[vitorpamplona]

Suggestion by @TonyGiorgio is lightning:invoice1&invoice2&invoice3

Any comments/concerns?

[saubyk]

Nostr allows users to set up split payments per post. Supporting clients must assemble individual LN invoices for each of the recipients and then pay them all. In Android, this creates several calls for payment to 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. 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.

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.

[vitorpamplona]

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.

I wouldn't bother specifying it in the lightning: URI space, since that's increasingly being replaced with unified bitcoin: BIP 21 links.

For bitcoin:, would we just do bitcoin:?lightning=LNBC..&lightning=LNBC..&lightning=LNBC..

Would parsers understand the reuse of a param?

[kristapsk]

I wouldn't bother specifying it in the lightning: URI space, since that's increasingly being replaced with unified bitcoin: BIP 21 links.

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 bitcoin:address?amount=0.001&lightning=invoice1&lightning=invoice2&lightning=invoice3. But, then again, not clear what that would mean - is these two alternative invoices you could pay instead of onchain, or should you pay all of them? If you add support for this at lightning: level, BIP21 URI could be bitcoin:address?amount=0.001&lightning=invoice1,invoice2,invoice3, for example (this shows that & as a separator would not be the best choice there).

[kristapsk]

Would parsers understand the reuse of a param?

BIP21 does not specify how to handle such situations, it's undefined behaviour.

[vitorpamplona]

bitcoin:address?amount&lightning=invoice1,invoice2,invoice3

Seems to make more sense.

BIP21 does not specify how to handle such situations, it's undefined behaviour.

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? :)

[vitorpamplona]

As an example, this URI

bitcoin:address?amount&lightning[0]=invoice1,invoice2,invoice3&lightning[1]=invoice3,invoice4,invoice5

could mean:

1. Pay via address OR (Pay any lightning[0] AND any lightning[1])

or it could mean

2. Pay via address OR all lightning[0] OR all lightning[1]

[vitorpamplona]

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.

[TheBlueMatt]

Why not bitcoin:?ln1=...&ln2=...&lightning=fallback? I'm not sure how wallets today handle this, but you could use this with a fallback BOLT11 to a node which will relay the payment onwards to the recipients, and wallets which understand this can know to pay to all the ln* params. In general I'd prefer separate params without any strange chars (no [s). I'm not sure how existing wallets would handle a missing address, but if you're defining a new spec that only some wallets will support then that's not a huge deal :).

I'd very much like to go rewrite BIP21 to much better capture forward- and backward-compatibility of bitcoin: URIs...

[vincenzopalazzo]

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.

lightning:<bolt11>&<bolt11>&<bolt12> to me sounds simple enough to parse in any kind of language and any kind of UX, because you need just to do string.split("&").foreach(invstr => ....)

Or from the grammar of BIP21

 bitcoinurn     = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]
 bitcoinaddress = *base58
 bitcoinparams  = bitcoinparam [ "&" bitcoinparams ]
 bitcoinparam   = [ amountparam / labelparam / messageparam / otherparam / reqparam ]
 amountparam    = "amount=" *digit [ "." *digit ]
 labelparam     = "label=" *qchar
 messageparam   = "message=" *qchar
 otherparam     = qchar *qchar [ "=" *qchar ]
 reqparam       = "req-" qchar *qchar [ "=" *qchar ]

we can build your own grammar where the bitcoinaddress is lightningaddresses defined as [ "&" lightningaddress ]

Or better like some programming languages do while supporting new syntax you can make a lightningaddress a lightningparam (this should be still left recursive grammar) and now you can have a retrocompatible way to parse a single address, and also to inject multiple address inside the parameters

any thought? I am missing something?

[vitorpamplona]

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.

lightning: doesn't have that semantical constraint and might be more aligned with the needs of the use case without having to worry about the formatting of AND/OR clauses.

[TheBlueMatt]

What's the URI size limit? At 135 invoices you may need to move to some kind of intent API.

[vincenzopalazzo]

What's the URI size limit? At 135 invoices you may need to move to some kind of intent API.

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!