Doesn't this solve the problem already?
```
if (req.query.nostr) {
// do zap stuff
}
```
It’s simply not compatible.
NIP57 zap mandates that the description hash of the invoice has to be the zap request note, whereas conventional with LNURL-pay invoices, it’s the LNURL-pay metadata that should be the desc hash.
So basically a zap is not really using LNURL-pay, it’s just the same URL endpoint.
So now all LNURL-pay servers has to also support this new propertary protocol.
If we’re going to think long-term, this can have some seriously bad implications, as both LNURL-pay and NIP57 progresses and moves forward.
But I can give you a clear-cut example: LUD-18 (https://github.com/lnurl/luds/blob/luds/18.md) also let’s you commit arbitrary payer identities to a payment (which is the primary goal of NIP57).
But seeing how NIP57 takes precedence, there’s no way to use NIP57 and LUD-18 at the same time, which is just sad.
To make things in the right way, zaps should’ve just used the already specified and established way to commit data, which is LUD-18.
Discussion
Yeah it solves it depending on how you view things. This introduces a completely new protocol. A hardfork.
So what happens if you want to use some LNURL-pay extension together with zaps, for example LUD-18 (https://github.com/lnurl/luds/blob/luds/18.md)?
You kinda can’t. All must obey NIP57, as it takes precedence.
I see your point. Perhaps they thought lud-18 wasn't sufficiently supported by wallets? speculating here.
I agree that it looks rushed. But it worked great for onboarding people and traction going on.
I see your point 👇
That said, it took one day for me to implement ln address with zap support. I can take another to support lud-18 if that overrides nip-57 at some point. But again, agreed protocols should be improved with foresight and alignment with what already exists.
#[3]
I am working on a zap protocol based LUD-18.
It will be very similar to NIP57, so should be easy to implement.
But it’s me against the world here, so I don’t really expect widespread support.
But I will at least try to do what I think is the right thing, instead of just complaining.
Let me know. I can try to support that. At least we can run some metrics about usage.
I don’t think it matters that LUD-18 wasn’t sufficiently supported by wallets.
Nostr clients want to consume the LNURL-pay code anyway and then send the BOLT11 invoice to the LN wallet, so zaps could’ve just used LUD-18 and wallets would not have to support LUD-18.
Though hypothetically, if wallets supported LUD-18 too, both nostr clients and LN wallets could support LUD-18 zaps.
Also, I’m not blaming people having fun with zaps. I’m just very sad and frustrated at how things came to be.
More #nostrica events, and the devs will get to know each other. Perhaps with time some will focus more on clients others on protocol level stuff. Currently everyone is almost everywhere. users ask, the devs deliver. Crazy and fun times at the same time.