NIP-57 Old zaps can't be authorized by clients if nostrPubkey is changed

[spcxta]

Given:

• Receiver of zap is R
• R or the LNURL provider of R can choose an authorized Zapper Z
• Pubkey of Z is published as field nostrPubkey at the LNURL-pay endpoint
• Clients only display/tally zap notes published by the current Zapper of R

So if nostrPubkey for R is changed for any reason (switching “provider”, zapper key rotation, …), old zaps can’t be authorized and won’t be displayed in clients anymore?

[fiatjaf]

Yes.

[spcxta]

This could be solved by putting the authorized nostrPubkey (signed by R) inside the zap note or zap request

[spcxta]

[fiatjaf]

This could be solved by putting the authorized nostrPubkey (signed by R) inside the zap note or zap request

As I suggested in #224, it would be better for each user to have the option to put multiple zap provider URLs along with their pubkeys inside their metadata event.

[shafemtol]

My 2 sats on this issue:

in order to retain previously received zaps, maybe one could define a new event type for explicitly authorizing old zaps via e tags and/or old nostrPubkeys via p tags, in the 10000-19999 (replaceable) or 30000-39999 (parameterized replaceable) range.

The idea being that for easy migration you just add the nostrPubkey, but if you no longer trust that key, there's the option to authorize old zaps individually.