[NIP-03] Validating OpenTimestamps

[nostr-protocol]

[NIP-03] Validating OpenTimestamps

[fiatjaf]

The idea is that you should be able to not do anything and things would still work. But if you're rejecting everything that has extra fields than you'll reject these and that may be a problem for clients that use NIP-03, so they may stop using your relay or not.

Or if you're removing the extra fields before storing the event then the event should still validate fine for everybody who download it from your relay and just not have that extra field. Which is not the worst thing in the world.

But I think that indicates NIP-03 is bad. I naïvely assumed relays would store the events in raw format as received, but that assumption is not good. For example, it allows one to make events that are filled with garbage in non-standard keys, and that is not good.

For NIP-03 specifically this is not possible, but in future NIPs if an extra field must be added we must make sure it is either a tag or part of the content.

Does that make sense?

[fiatjaf]

Oh, about the duplicate events I think that shouldn't be an issue. I imagine clients will probably add the first ots field before publishing the event to any relay.

But in any case accepting the first event with each id is probably the saner approach. My relay is also doing that.

[melvincarvalho]

From the NIP:

The event id MUST be used as the raw hash to be included in the OpenTimestamps merkle tree.

@scsibug re:

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?

The event id is in the OTS file, so, the ots field cant change the event id or be part of the serialization

It's meta data, essentially. What is says is that this event has proof of publication at a certain time

Also it cant go in a tag, as that would then change the event id again