hampus on Nostr: It’s simply not compatible. NIP57 zap mandates that the description hash of the ...
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.
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.