From a4c7d038eb71b59af8e311197c26cf251e264f41 Mon Sep 17 00:00:00 2001 From: arthurfranca Date: Thu, 18 May 2023 10:21:07 -0300 Subject: [PATCH 1/3] Add ! as authorized deletion pubkey tag --- 09.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/09.md b/09.md index fbbd6e1353..31e129f34e 100644 --- a/09.md +++ b/09.md @@ -28,7 +28,7 @@ For example: } ``` -Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. +Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request OR that have a `!` tag value equal to the deletion request `pubkey`. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it. @@ -36,13 +36,13 @@ Relays SHOULD continue to publish/share the deletion events indefinitely, as cli Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content. -A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. +A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey` OR that each referenced event has `!` tag value equal to the deletion request `pubkey` before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice. ## Relay Usage -Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself, however this is not required since relays may not have knowledge of all referenced events. +Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself or that have a `!` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events. ## Deleting a Deletion From a767d374113a42c4ba081cf9bec8b702bdeafab3 Mon Sep 17 00:00:00 2001 From: arthurfranca Date: Mon, 28 Aug 2023 21:43:37 -0300 Subject: [PATCH 2/3] Exclude author from ! rule --- 01.md | 4 ++-- 09.md | 8 ++++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/01.md b/01.md index 80ee7924a5..76e67adc4e 100644 --- a/01.md +++ b/01.md @@ -82,7 +82,7 @@ This NIP defines 3 standard tags that can be used across all event kinds with th - for a parameterized replaceable event: `["a", :<32-bytes lowercase hex of a pubkey>:, ]` - for a non-parameterized replaceable event: `["a", :<32-bytes lowercase hex of a pubkey>:, ]` -As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter. +As a convention, all single-letter (only english alphabet letters: a-z, A-Z) and single-char exclamation mark key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter. ### Kinds @@ -125,7 +125,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th "ids": , "authors": , "kinds": , - "#": , + "#": , "since": , "until": , "limit": diff --git a/09.md b/09.md index 31e129f34e..8a3791b23a 100644 --- a/09.md +++ b/09.md @@ -28,7 +28,11 @@ For example: } ``` -Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request OR that have a `!` tag value equal to the deletion request `pubkey`. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. +Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. +When a referenced event contains `!` tags(s), however, **instead of the former rule**, relays SHOULD only honor +deletion requests with a `pubkey` that matches one of the `!` tags values. + +Clients SHOULD hide or otherwise indicate a deletion status for referenced events. Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it. @@ -42,7 +46,7 @@ Clients display the deletion event itself in any way they choose, e.g., not at a ## Relay Usage -Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself or that have a `!` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events. +Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself OR that have a `!` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events. ## Deleting a Deletion From 921605e44a4237f51543d53e47163f254b43fbd3 Mon Sep 17 00:00:00 2001 From: arthurfranca Date: Tue, 29 Aug 2023 18:00:34 -0300 Subject: [PATCH 3/3] Change tag key to z --- 01.md | 4 ++-- 09.md | 8 ++++---- README.md | 1 + 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/01.md b/01.md index 76e67adc4e..80ee7924a5 100644 --- a/01.md +++ b/01.md @@ -82,7 +82,7 @@ This NIP defines 3 standard tags that can be used across all event kinds with th - for a parameterized replaceable event: `["a", :<32-bytes lowercase hex of a pubkey>:, ]` - for a non-parameterized replaceable event: `["a", :<32-bytes lowercase hex of a pubkey>:, ]` -As a convention, all single-letter (only english alphabet letters: a-z, A-Z) and single-char exclamation mark key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter. +As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter. ### Kinds @@ -125,7 +125,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th "ids": , "authors": , "kinds": , - "#": , + "#": , "since": , "until": , "limit": diff --git a/09.md b/09.md index 8a3791b23a..ff7a0bb745 100644 --- a/09.md +++ b/09.md @@ -29,8 +29,8 @@ For example: ``` Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. -When a referenced event contains `!` tags(s), however, **instead of the former rule**, relays SHOULD only honor -deletion requests with a `pubkey` that matches one of the `!` tags values. +When a referenced event contains `z` tags(s), however, **instead of the former rule**, relays SHOULD only honor +deletion requests with a `pubkey` that matches one of the `z` tags values. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. @@ -40,13 +40,13 @@ Relays SHOULD continue to publish/share the deletion events indefinitely, as cli Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content. -A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey` OR that each referenced event has `!` tag value equal to the deletion request `pubkey` before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. +A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey` OR that each referenced event has `z` tag value equal to the deletion request `pubkey` before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice. ## Relay Usage -Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself OR that have a `!` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events. +Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself OR that have a `z` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events. ## Deleting a Deletion diff --git a/README.md b/README.md index 678818d555..e4c5bdaa03 100644 --- a/README.md +++ b/README.md @@ -197,6 +197,7 @@ Please update these lists when proposing NIPs introducing new event kinds. | `r` | a reference (URL, etc) | petname | | | `r` | relay url | marker | [65](65.md) | | `t` | hashtag | -- | | +| `z` | authorized deletion pubkey (hex) | -- | [09](09.md) | | `alt` | summary | -- | [31](31.md) | | `amount` | millisatoshis, stringified | -- | [57](57.md) | | `bolt11` | `bolt11` invoice | -- | [57](57.md) |