nostr icon indicating copy to clipboard operation
nostr copied to clipboard

[NIP-03] Validating OpenTimestamps

Open scsibug opened this issue 3 years ago • 3 comments

I'm trying to understand if I need to do anything (as the author of a relay) to support NIP-03.

If a client sends an event that includes an ots field, should that be used for serialization to determine the event ID and verifying a signature? Or is it simply ignored for signature validation, and passed along if present?

I know in my relay, I make a strong assumption that events are unique - someone attempting to publish an event with the same 'id' as an existing one will simply be ignored. But with the ots addition, this introduces two distinct events, with the same id/signature, but they have a different serialization (one with the ots, one without). What would happen if a client received the same event id from two relays, but with different ots fields?

Again, my concern is primarily from the relay perspective. I don't accept events that contain fields other than those specified in NIP-01 (NIP-03 events would be rejected), so I'm curious about the correct way to extend things to allow handling that extension. Right now, the easiest thing would be to essentially say, "first publisher wins", for events with ots fields, but perform no validation.

If this is merely a hint field, perhaps the simplest/right answer for me is to simply accept events that have ots fields, but never serialize or re-publish them. That way I don't break clients that use ots.

scsibug avatar Dec 19 '21 16:12 scsibug