I just added lightning network support to Semaphore. Semaphore fundraisers now have feature parity with Geyser fundraisers, except Semaphore doesn't have any fees. (Geyser charges a 2% fee on all lightning contributions.)
Try it out! https://semaphore.finance/
Note that making lightning payments reversible would require additional trust assumptions, which I don't want to introduce. Consequently, contributors only see the "pay with lightning" option if they choose to do an irreversible pledge.
Also, I don't know how to automatically & reliably detect lightning payments without running some sort of middleman server, so I have the contributor just "tell the site" they made the payment by pasting their preimage. Semaphore then verifies that the preimage matches what the recipient's invoice expects and only counts the contribution toward the goal if the preimage matches.
(Technically I guess that means Semaphore doesn't quite have feature parity with Geyser. Geyser does automatically detect lightning payments, so you don't have to copy/paste a preimage to prove you did it. They are able to autodetect them because they are running a middleman server, which they do in order to take their cut.)
I know Super knows this because we've talked about it before, but the only way to do this is to be on the payment route. One of my biggest pie in the sky wishes in service of Lightning apps is atomic payments to multiple recipients that somehow doesn't rely on recipients being along the route.
Naively, recipients would have to coordinate and possibly even have a contract between each other, which eventually begins to look like a lightning channel (surprise), but maybe there's some other clever way.
I'm not willing to say certainly that it is the "only" way. But it is one way, and I think it's pretty neat, and possibly good enough, if some elbow grease is put into making it work well
Correct me if I'm wrong but I don't think you are inherently opposed to each recipient being on the route, I suspect you just see that as bringing additional challenges that you don't know how to overcome. Some of those challenges include:
I think with some elbow grease those challenges are overcome-able. Just-in-time-routing is pretty magical if someone is online, and if they are definitely offline, zaplocker demonstrates that an intermediary can atomically hold a payment for someone til they get online to collect it, without taking custody.
Someday I'd like to see how close LN can get to "one sender, many recipients" using those tools. The sender's device could figure out which parties are online and construct a route "though" them using just-in-time routing tools, if necesary, to ensure everyone has enough inbound and outbound capacity to do their part, and if someone is definitely offline, it could send their payment to a zaplocker server as a kind of docking station, knowing that the server won't be able to keep the funds, but they'll either return to the sender or go to the recipient when they next get online.
Correct, it's just inconvenient.
At least for the challenges I'm immediately concerned with, I know how to overcome them.[1] However atomic splits done this way require each intermediate recipient have:
In addition to being reliably online.
I think about this problem in the context of taking an SN-like sybil fee, ie a third party verifying a payment happened and taking a fee without additional interaction from the sender and receiver. The third party can do this by "wrapping" a bolt11 from the destination in a hold invoice paid to itself. This would work for multiple third parties too with each wrapping the bolt11 of one of the other third parties. ↩