mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
migrate nips from main nostr repo.
This commit is contained in:
46
09.md
Normal file
46
09.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user