Thread - Nostr Hypermedia

The s-tag is for the signature of the reference event. Just to be sure, when you refer to the "standard OTS spec," I hope you don't mean the old broken NIP-03 where the item that gets timestamped only includes the event_id and does not include the signature (see below for some discussion of this). Also, I think splicing the OTS proof into the event that gets returned by the relay is essential so that clients get proof simultaneously with the event. I think that's precisely the role that relays need to play because it's a huge pain for a client to have to fetch an OTS event separately when trying to filter out events that don't have a valid OTS proof. I guess I find AI-written specs useful. They are both human-readable and can be fed to an AI to get oriented in the project without skipping too much detail. Also, the proposed modifications to the relay were made by an AI and the AI has a better grasp of the details.

inkan

If NIP-3 is going to change, the most important thing to incorporate into the updated specification is that the item that gets timestamped must include both the *event_id* and the *signature* of the target event. I think including the signature is quite crucial. See below for discussion with @npub1gzuu...a5ds about this issue. The ideal shape for an OTS event should also include something like a p-tag for the pubkey of the target event, a c-tag for the created_at time of the target event, a b-tag for the bitcoin block that anchors the timestamp, and a t-tag for the time of that bitcoin block. I'm using OTS timestamping extensively as part of the Inkan key revocation and replacement system. The above is what I've concluded is needed after a lot of experimenting. View quoted note →

View quoted note →

Replies (1)