Following this, looking for this solution for some years now

Could possibly add a split payload to CLINK offers responses that loads n additional invoices or offers for other parties. The primary offer publisher is still trusted to serve those though, but, never holds the funds themselves. Alternatively, chain n offers together into one string, with a delimiter where clients sequentially pay each. Biggest issue I see with that would be the strings become extremely long and ugly and it wouldn't work with QR codes The latter would probably work fine in shops UX's specifically though, assuming there was a debit wallet connection to handle the long strings without QR scanning/copypasta The issue is that Lightning itself can't natively split payments so it's ultimately always going to be some hacky way of sequencing multiple payments that aren't atomic. Open to other thoughts, the latter is a trivial CLINK/SDK addition with no work on the reference server and I can tinker with it in our in progress shops UI on Bxrd.

I think that with the cafe selling the bag of coffee, its impossible to avoid trust. I bet there is something clever you could do with the supply chain, as in get a proof, attached to an identity, for all the people who were paid at point of sale. We have LN and nostr, it must be possible.

Like have some supply chain qrcode on the bag, linking to the npubs, and the payment they received when you bought it.

Or something more fancy shmancy

For sure. I'm working on something else but it's a problem in need of a solution imo. View quoted note →

> Lightning itself can't natively split payments I think it can. If the wallet knows it wants to pay 400 sats to Alice, 300 to Bob, and 500 to Carol, it can arrange a route that passes through each of their nodes, and drop pending fee htlcs off at each one, whose value corresponds to the amount desired for that node. The last node reveals the preimage and then everyone gets paid. That's an atomic split payment that lightning has native support for.

👀

I like that! Because I presume the payment to Alice, Bob and Carol is atomic in the sense all or nothing.

@Ben Weeks ⚡ the all or nothing gap is the real blocker, zap splits fire as independent zaps so one leg failing just underpays the farmer. atomic multiparty needs something like ptlcs or a hold-invoice coordinator that settles every leg together, which quietly reintroduces the custody point you are removing.