upleb.uk

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

summaryrefslogtreecommitdiff
path: root/09.md
diff options
context:
space:
mode:
authorfiatjaf <faitjaf@gmail.com>2022-05-01 07:48:57 -0300
committerfiatjaf <faitjaf@gmail.com>2022-05-01 07:48:57 -0300
commitf25c7e672c23ca5463fa5c0fcb5e5f424d956862 (patch)
tree597462ec02ed56ef53f268279a31f62edd3f37eb /09.md
migrate nips from main nostr repo.
Diffstat (limited to '09.md')
-rw-r--r--09.md46
1 files changed, 46 insertions, 0 deletions
diff --git a/09.md b/09.md
new file mode 100644
index 0000000..0a0d149
--- /dev/null
+++ b/09.md
@@ -0,0 +1,46 @@
1NIP-09
2======
3
4Event Deletion
5--------------
6
7`draft` `optional` `author:scsibug`
8
9A 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.
10
11Each tag entry must contain an "e" event id intended for deletion.
12
13The event's `content` field MAY contain a text note describing the reason for the deletion.
14
15For example:
16
17```
18{
19 "kind": 5,
20 "pubkey": <32-bytes hex-encoded public key of the event creator>,
21 "tags": [
22 ["e", "dcd59..464a2"],
23 ["e", "968c5..ad7a4"],
24 ],
25 "content": "these posts were published by accident",
26 ...other fields
27}
28```
29
30Relays 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.
31
32## Client Usage
33
34Clients 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.
35
36A 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.
37
38Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice.
39
40## Relay Usage
41
42Relays 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.
43
44## Deleting a Deletion
45
46Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality.