upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorfiatjaf_ <fiatjaf@gmail.com>2023-10-11 10:17:43 -0300
committerGitHub <noreply@github.com>2023-10-11 10:17:43 -0300
commit09ffb951c69343312486aaff2726dca04bc42f6e (patch)
treee84281d461dc220996cf96e771af8f0cf177901e
parent324c7aafdcd316fb971c1f26b964d2b53c939a10 (diff)
rework NIP-03 so it is actually usable (#804)
* rework nip-03 to be actually useful and usable. * fixes. * add ots verification flow.
-rw-r--r--03.md33
-rw-r--r--README.md1
2 files changed, 24 insertions, 10 deletions
diff --git a/03.md b/03.md
index 3c5d764..4faf3f1 100644
--- a/03.md
+++ b/03.md
@@ -4,20 +4,33 @@ NIP-03
4OpenTimestamps Attestations for Events 4OpenTimestamps Attestations for Events
5-------------------------------------- 5--------------------------------------
6 6
7`draft` `optional` `author:fiatjaf` 7`draft` `optional` `author:fiatjaf` `author:constant`
8 8
9When there is an OTS available it MAY be included in the existing event body under the `ots` key: 9This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event:
10 10
11``` 11```json
12{ 12{
13 "id": ..., 13 "kind": 1040
14 "kind": ..., 14 "tags": [
15 ..., 15 ["e", <event-id>, <relay-url>],
16 ..., 16 ["block", <block-height-as-string>, <block-hash>],
17 "ots": <base64-encoded OTS file data> 17 ["alt", "opentimestamps attestation"]
18 ],
19 "content": <base64-encoded OTS file data>
18} 20}
19``` 21```
20 22
21The _event id_ MUST be used as the raw hash to be included in the OpenTimestamps merkle tree. 23- The OpenTimestamps proof MUST prove the referenced `e` event id as its digest.
24- The `block` tag is optional, it exists to establish a minimum date since which the given event has existed.
25- 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.
26
27### Example OpenTimestamps proof verification flow
22 28
23The 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]". 29Using [`nak`](https://github.com/fiatjaf/nak), [`jq`](https://jqlang.github.io/jq/) and [`ots`](https://github.com/fiatjaf/ots):
30
31```bash
32~> nak req -i e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323 wss://nostr-pub.wellorder.net | jq -r .content | ots verify
33> using an esplora server at https://blockstream.info/api
34- sequence ending on block 810391 is valid
35timestamp validated at block [810391]
36```
diff --git a/README.md b/README.md
index dc70887..e9f08bd 100644
--- a/README.md
+++ b/README.md
@@ -92,6 +92,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
92| `44` | Channel Mute User | [28](28.md) | 92| `44` | Channel Mute User | [28](28.md) |
93| `1063` | File Metadata | [94](94.md) | 93| `1063` | File Metadata | [94](94.md) |
94| `1311` | Live Chat Message | [53](53.md) | 94| `1311` | Live Chat Message | [53](53.md) |
95| `1040` | OpenTimestamps | [03](03.md) |
95| `1984` | Reporting | [56](56.md) | 96| `1984` | Reporting | [56](56.md) |
96| `1985` | Label | [32](32.md) | 97| `1985` | Label | [32](32.md) |
97| `4550` | Community Post Approval | [72](72.md) | 98| `4550` | Community Post Approval | [72](72.md) |