NIP-59: Lightning Zaps v2

[ok300]

This is an alternative implementation of Zaps.

The goal is to achieve the same outcomes as the original NIP-57, but in a simpler and more robust way.

https://github.com/ok300/nips/blob/nip-59-zap-v2/59.md

[Egge21M]

If I am not mistaken that would mean that LNURL servers would have to listen for nostr events in order to implement this, right?

[ok300]

Yes, there would have to be a service that converts outside signals into LN invoices and returns them.

LNURL does that with HTTP: it listens to HTTP requests and converts them to invoices (among other things).

The Zapper in this PR would be a similar service that listens on nostr and converts certain types of events to invoices.

If LN is Layer 2, then LNURL and the Zapper are Layer 3. But LNURL is not used here.

[Egge21M]

I feel like these services would need a lot more resources and overhead to be as reachable as a HTTP lnurl-Server, while doing pretty much the same thing. Or am I missing a benefit of Zappers over LNURL?

[fiatjaf]

So you need a dedicated server to be able to send payments? You can't do it from your mobile standalone wallet? That's a deal breaker.

[ok300]

@Egge7 you mean because of this?

[5] monitors invoice, when paid it posts a ZapReceipt nostr event

I realized it's a mistake to keep state and monitor the invoice. Working on a change which gets rid of this.

@fiatjaf this is not replacing LNURL, people can still send payments from a mobile wallet. But having their nostr ID publicly linked to a payment they made to another nostr ID, that's functionality that IMO needs a Zapper. People already pay for NIP-05 verification (or host it themselves), I see the Zapper as a similar service. Can't run on the phone, but ultra-slim IMO, ideally would run on an Umbrel.

Update: the Zapper itself can't run on the phone, but triggering a payment can of course be done from a phone nostr client.

[fiatjaf]

using the preimage, decrypt the ZapReceipt

In this case this part becomes impossible to do. Unfortunately it's often impossible to get the preimage for a payment I made on my mobile Lightning wallet into my Nostr client -- which may or may not be running on the same device. Even if I could do that it would still be a giant hassle and a deal breaker for most users.

I think this would be a pretty nice flow if most wallets had implemented https://github.com/lnurl/luds/blob/luds/10.md and they could click on it to "share" and then share it to their Nostr app. I would love that. But we are way too far ahead from that reality, and we're probably never going to get there. In the meantime the current zap proposal works well enough, so it is hard to argue against it.

[ok300]

Impossible to do, assuming the preimage handling happens on the client (phone). But it is possible if the client delegates its "zapping" to its own Zapper.

Yes, this limitation on the client device frustrated me when looking for ways to improve NIP-57. I don't think there's a seamless way to pass along data between apps as a sort of "callback", like preimage or as you said, the decrypted LUD-10 AES payload. That would be cool, and when that happens this NIP becomes obsolete.

Here's a rudimentary demo of what I had in mind. I added a delay between each step in the workflow to better follow who is doing what. (Gif can be opened in its own tab, its higher resolution than what the GitHub width allows here).

About the demo:

• I simulated a Zapper with a JS nostr client + WebLN
• The Zap Log in the Zappers shows relevant Zap nostr messages affecting that Zapper
• Notice no further client interaction is needed after pressing Zap (ignore the Alby popup)
• Notice the invoce mgmt (creating and paying) happens among the Zappers

[fiatjaf]

Sorry, @ok300, there is no point to proposal. Unfortunately it is what it is. I'll close this to prevent you from wasting more of your time.

[ok300]

I'll continue with this somewhere else, still think its worth exploring.

Thanks for the feedback so far.