From f25c7e672c23ca5463fa5c0fcb5e5f424d956862 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 1 May 2022 07:48:57 -0300 Subject: migrate nips from main nostr repo. --- 09.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 09.md (limited to '09.md') diff --git a/09.md b/09.md new file mode 100644 index 0000000..0a0d149 --- /dev/null +++ b/09.md @@ -0,0 +1,46 @@ +NIP-09 +====== + +Event Deletion +-------------- + +`draft` `optional` `author:scsibug` + +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. + +Each tag entry must contain an "e" event id intended for deletion. + +The event's `content` field MAY contain a text note describing the reason for the deletion. + +For example: + +``` +{ + "kind": 5, + "pubkey": <32-bytes hex-encoded public key of the event creator>, + "tags": [ + ["e", "dcd59..464a2"], + ["e", "968c5..ad7a4"], + ], + "content": "these posts were published by accident", + ...other fields +} +``` + +Relays MAY delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. Clients may hide or otherwise indicate a deletion status for referenced events. + +## Client Usage + +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. + +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. + +## Deleting a Deletion + +Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality. -- cgit v1.2.3