nips/03.md

76 lines
3.0 KiB
Markdown
Raw Normal View History

2022-05-01 10:48:57 +00:00
NIP-03
======
Notarizing Events
-----------------
2022-05-01 10:48:57 +00:00
2023-11-16 00:42:51 +00:00
`draft` `optional`
2022-05-01 10:48:57 +00:00
This NIP defines strategies for establishing when an event was first found on the nostr network:
- [OpenTimestamps](#opentimestamps)
- [Relay Notaries](#relay-notaries)
- [Peer Notaries](#peer-notaries)
# OpenTimestamps
An event with `kind:1040` contains an [OpenTimestamps](https://opentimestamps.org/) proof for any event:
2022-05-01 10:48:57 +00:00
```json
2022-05-01 10:48:57 +00:00
{
"kind": 1040
"tags": [
["e", <event-id>, <relay-url>],
["alt", "opentimestamps attestation"]
],
"content": <base64-encoded OTS file data>
2022-05-01 10:48:57 +00:00
}
```
- The OpenTimestamps proof MUST prove the referenced `e` event id as its digest.
- The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.
## Example OpenTimestamps proof verification flow
2022-05-01 10:48:57 +00:00
Using [`nak`](https://github.com/fiatjaf/nak), [`jq`](https://jqlang.github.io/jq/) and [`ots`](https://github.com/fiatjaf/ots):
```bash
~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify
> using an esplora server at https://blockstream.info/api
- sequence ending on block 810391 is valid
timestamp validated at block [810391]
```
# Relay Notaries
Relays MAY notarize events by supporting a `NOTARY` message.
- First a client sends a `NOTARY` message to the relay with an event id as the first argument.
- Next, the relay MAY respond with a `NOTARY` message with the same event id as the first argument and a timestamp matching when the relay first saw the event as the second argument.
- If the relay has not seen the event it SHOULD respond with `null` in the timestamp field.
Example:
```jsonc
-> ["NOTARY", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323"]
<- ["NOTARY", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323", 1738617405]
```
Note that relay-provided notaries provide a weaker guarantee than OTS proofs. Depending on the importance of the verification, multiple relays with a good reputation should be consulted in order to determine a reasonable result.
# Peer Notaries
Users MAY notarize events by publishing a `kind:4341` event. `content` MAY provide any human-readable explanation of the event. One or more `notary` tags MUST be included indicating event ids and timestamps. Event addresses MUST NOT be used.
```jsonc
{
"content": "I vaguely remember hearing about this note last year",
"tags": [
["alt", "A notary event"],
["notary", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323", 1738617405]
]
}
```
Note that user-provided notaries provide a weaker guarantee than OTS proofs. Depending on the importance of the verification, multiple users with a good reputation should be consulted in order to determine a reasonable result.