Nostr Web Client

A node (client or relay) that doesn't upgrade will see these as broken invalid events. The signature will not match the pubkey field.

In the current NIP-26, at least the events are valid and people can see them, they just don't have a clear association between the signer and the delegator.

So I think this is a worse experience for nodes that don't upgrade.

If every node upgraded it would be fine, but I'm not sure it would be better. Both ways of doing it require code to update either it's signature verification or it's method of associating an author, neither being a harder ask IMHO.

BTW the delegation proof doesn't have to be replicated in every event if we wanted to save space, it could be a separate event.

daniele 1y ago

I also was worried to the idea to spread invalid events; for this reason the NIP is flagged as mandatory.

You are certainly more qualified than I am to express the complexity of an upgrade, but the extended signature check seems to me easier, and it also keeps the events with the same human-readable structure related to the `pubkey`.

> BTW the delegation proof doesn't have to be replicated in every event if we wanted to save space, it could be a separate event.

A delegation proof is ~280B, is it worth the risk of invalidating an event because the proof was not founded? Or adding an async pattern and wait more time to fetch it?

Reply to this note

Please Login to reply.

Discussion

fiatjaf 1y ago

I think having the delegation proof immediately accessible may be very important.

But the mandatoryness or the invalidness of all events by non-supporting clients may be too much of a barrier, such that I think it might be better to try all the other alternatives first.