From 497c505879fc2cb91a73879530578af6d8338f8d Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Mon, 3 Feb 2025 13:27:54 -0800 Subject: [PATCH 1/5] Expand NIP 03 to include relay and user notaries --- 03.md | 49 +++++++++++++++++++++++++++++++++++++++++++++---- README.md | 1 + 2 files changed, 46 insertions(+), 4 deletions(-) diff --git a/03.md b/03.md index 74e010cb69..477bef4758 100644 --- a/03.md +++ b/03.md @@ -1,12 +1,20 @@ NIP-03 ====== -OpenTimestamps Attestations for Events --------------------------------------- +Notarizing Events +----------------- `draft` `optional` -This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event: +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: ```json { @@ -22,7 +30,7 @@ This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps]( - 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 +## 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): @@ -32,3 +40,36 @@ Using [`nak`](https://github.com/fiatjaf/nak), [`jq`](https://jqlang.github.io/j - 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. diff --git a/README.md b/README.md index 3f416a2c98..d4f15db527 100644 --- a/README.md +++ b/README.md @@ -150,6 +150,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `2003` | Torrent | [35](35.md) | | `2004` | Torrent Comment | [35](35.md) | | `2022` | Coinjoin Pool | [joinstr][joinstr] | +| `4341` | Peer notary | [03](03.md) | | `4550` | Community Post Approval | [72](72.md) | | `5000`-`5999` | Job Request | [90](90.md) | | `6000`-`6999` | Job Result | [90](90.md) | From 980902bb2cdd08dde84cb71f0abe636f1022bda8 Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Mon, 3 Feb 2025 13:35:02 -0800 Subject: [PATCH 2/5] Simplify timestamp attestations --- 03.md | 37 ++++++++++++------------------------- README.md | 2 +- 2 files changed, 13 insertions(+), 26 deletions(-) diff --git a/03.md b/03.md index 477bef4758..ab9795a269 100644 --- a/03.md +++ b/03.md @@ -1,16 +1,15 @@ NIP-03 ====== -Notarizing Events ------------------ +Timestamp Attestations for Events +--------------------------------- `draft` `optional` 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) +- [Attestation Event](#attestation-event) # OpenTimestamps @@ -41,35 +40,23 @@ Using [`nak`](https://github.com/fiatjaf/nak), [`jq`](https://jqlang.github.io/j timestamp validated at block [810391] ``` -# Relay Notaries +# Attestation Event -Relays MAY notarize events by supporting a `NOTARY` message. +Users MAY verify when they first saw an event by publishing a `kind:4341` event. -- 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. +- One or more `stamp` tags MUST be included indicating event ids and timestamps. Event addresses MUST NOT be used. +- The `content` field MAY provide any human-readable explanation of the event.- ```jsonc { "content": "I vaguely remember hearing about this note last year", "tags": [ - ["alt", "A notary event"], - ["notary", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323", 1738617405] + ["alt", "A timestamp attestation event"], + ["stamp", "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. +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. diff --git a/README.md b/README.md index d4f15db527..20ac4b5af3 100644 --- a/README.md +++ b/README.md @@ -150,7 +150,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `2003` | Torrent | [35](35.md) | | `2004` | Torrent Comment | [35](35.md) | | `2022` | Coinjoin Pool | [joinstr][joinstr] | -| `4341` | Peer notary | [03](03.md) | +| `4341` | Timestamp Attestation | [03](03.md) | | `4550` | Community Post Approval | [72](72.md) | | `5000`-`5999` | Job Request | [90](90.md) | | `6000`-`6999` | Job Result | [90](90.md) | From a7bfdb398f4ebc17f97e268ff85481009dc982d0 Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Mon, 3 Feb 2025 13:42:44 -0800 Subject: [PATCH 3/5] Add k tag to kind 4341 --- 03.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/03.md b/03.md index ab9795a269..cf21c3ec70 100644 --- a/03.md +++ b/03.md @@ -45,14 +45,17 @@ timestamp validated at block [810391] 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. -- The `content` field MAY provide any human-readable explanation of the event.- +- 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] + ["stamp", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323", 1738617405], + ["k", "10002"] ] } ``` From e2d6b7d16591b0af027e9d5765d6bf83d4a2c1c1 Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Fri, 7 Feb 2025 16:00:24 -0800 Subject: [PATCH 4/5] Use standard e tag for attestations --- 03.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/03.md b/03.md index cf21c3ec70..5e6f91181b 100644 --- a/03.md +++ b/03.md @@ -44,7 +44,7 @@ timestamp validated at block [810391] 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 `e` 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. @@ -52,9 +52,10 @@ Users MAY verify when they first saw an event by publishing a `kind:4341` event. { "kind": 4341, "content": "I vaguely remember hearing about this note last year", + "created_at": 1738617405, "tags": [ ["alt", "A timestamp attestation event"], - ["stamp", "e71c6ea722987debdb60f81f9ea4f604b5ac0664120dd64fb9d23abc4ec7c323", 1738617405], + ["e", "", "", ""], ["k", "10002"] ] } @@ -62,4 +63,4 @@ Users MAY verify when they first saw an event by publishing a `kind:4341` event. 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. +Relays MAY also provide these attestations by generating and signing them on the fly using the `self` pubkey listed in the relay's [NIP 11](./11.md) document. From 686d2419d1a5155d78aea642be7883b9149de128 Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Mon, 10 Feb 2025 12:33:13 -0800 Subject: [PATCH 5/5] Wording change --- 03.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/03.md b/03.md index 5e6f91181b..65fae7c08d 100644 --- a/03.md +++ b/03.md @@ -44,7 +44,7 @@ timestamp validated at block [810391] Users MAY verify when they first saw an event by publishing a `kind:4341` event. -- One or more `e` tags MUST be included indicating event ids and timestamps. Event addresses MUST NOT be used. +- One or more `e` tags MUST be included indicating event id, relay url, and author pubkey. 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.