rework NIP-03 so it is actually usable (#804)

* rework nip-03 to be actually useful and usable.
* fixes.
* add ots verification flow.
This commit is contained in:
fiatjaf_ 2023-10-11 10:17:43 -03:00 committed by GitHub
parent 324c7aafdc
commit 09ffb951c6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 24 additions and 10 deletions

33
03.md
View File

@ -4,20 +4,33 @@ NIP-03
OpenTimestamps Attestations for Events OpenTimestamps Attestations for Events
-------------------------------------- --------------------------------------
`draft` `optional` `author:fiatjaf` `draft` `optional` `author:fiatjaf` `author:constant`
When there is an OTS available it MAY be included in the existing event body under the `ots` key: This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event:
``` ```json
{ {
"id": ..., "kind": 1040
"kind": ..., "tags": [
..., ["e", <event-id>, <relay-url>],
..., ["block", <block-height-as-string>, <block-hash>],
"ots": <base64-encoded OTS file data> ["alt", "opentimestamps attestation"]
],
"content": <base64-encoded OTS file data>
} }
``` ```
The _event id_ MUST be used as the raw hash to be included in the OpenTimestamps merkle tree. - The OpenTimestamps proof MUST prove the referenced `e` event id as its digest.
- The `block` tag is optional, it exists to establish a minimum date since which the given event has existed.
- 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 and no reference to "pending" attestations since they are useless in this context.
The attestation can be either provided by relays automatically (and the OTS binary contents just appended to the events it receives) or by clients themselves when they first upload the event to relays — and used by clients to show that an event is really "at least as old as [OTS date]". ### 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]
```

View File

@ -92,6 +92,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `44` | Channel Mute User | [28](28.md) | | `44` | Channel Mute User | [28](28.md) |
| `1063` | File Metadata | [94](94.md) | | `1063` | File Metadata | [94](94.md) |
| `1311` | Live Chat Message | [53](53.md) | | `1311` | Live Chat Message | [53](53.md) |
| `1040` | OpenTimestamps | [03](03.md) |
| `1984` | Reporting | [56](56.md) | | `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) | | `1985` | Label | [32](32.md) |
| `4550` | Community Post Approval | [72](72.md) | | `4550` | Community Post Approval | [72](72.md) |