From 7c999e554d862ae8577a13852a9d40eda26c76ee Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Thu, 28 Mar 2024 12:29:55 -0400 Subject: [PATCH] Simply NIP-09 Deletions and Add time-limitation for `a` tags --- 09.md | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/09.md b/09.md index fbbd6e13..dac74938 100644 --- a/09.md +++ b/09.md @@ -6,13 +6,9 @@ Event Deletion `draft` `optional` -A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted. +Event kind `5` describes a deletion event. It MUST contain a list of one or more `e` or `a` tags, each referencing the events the author is requesting to be deleted. -Each tag entry must contain an "e" event id and/or `a` tags intended for deletion. - -The event's `content` field MAY contain a text note describing the reason for the deletion. - -For example: +The `.content` MAY contain the reason for the deletion. ``` { @@ -28,22 +24,18 @@ 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. +Supporters MUST verify if the `pubkey` of the Deletion event is the same as the `pubkey` of the 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. +Deletion events referencing an `a` tag delete all the referenced events up Deletion event's `created_at`. -## Client Usage +Relays SHOULD delete or stop publishing any referenced events of the deletion request. -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. +Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. -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. +Clients SHOULD hide or otherwise indicate a deletion status for referenced events. -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. +Clients SHOULD broadcast deletion events to other relays which don't have it. ## Deleting a Deletion -Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality. +Publishing a deletion event against a deletion has no effect. \ No newline at end of file