nips/03.md

NIP-03
======

Timestamp Attestations for Events
---------------------------------

`draft` `optional`

This NIP defines strategies for establishing when an event was first found on the nostr network:

- [OpenTimestamps](#opentimestamps)
- [Attestation Event](#attestation-event)

# OpenTimestamps

An event with `kind:1040` contains an [OpenTimestamps](https://opentimestamps.org/) proof for any event:

```json
{
  "kind": 1040
  "tags": [
    ["e", <event-id>, <relay-url>],
    ["alt", "opentimestamps attestation"]
  ],
  "content": <base64-encoded OTS file data>
}
```

- 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

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]
```

# Attestation Event

Users MAY verify when they first saw an event by publishing a `kind:4341` event.

- One or more `stamp` tags MUST be included indicating event ids and timestamps. Event addresses MUST NOT be used.
- One or more `k` tags SHOULD be included indicating the kind(s) of the event(s) being referred to.
- The `content` field MAY provide any human-readable explanation of the event.

```jsonc
{
  "kind": 4341,
  "content": "I vaguely remember hearing about this note last year",
  "tags": [
    ["alt", "A timestamp attestation event"],
    ["stamp", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323", 1738617405],
    ["k", "10002"]
  ]
}
```

Note that user-provided attestations 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.

Relays MAY also provide these attestations by generating and signing them on the fly using the pubkey listed in the relay's [NIP 11](./11.md) document.