mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-09 22:09:06 -05:00
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
NIP-09
|
|
======
|
|
|
|
Event Retraction
|
|
--------------
|
|
|
|
`draft` `optional`
|
|
|
|
A special event with kind `5`, meaning "retraction" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be retracted. Retraction requests SHOULD include a `k` tag for the kind of each event being retracted.
|
|
|
|
The event's `content` field MAY contain a text note describing the reason for the retraction.
|
|
|
|
For example:
|
|
|
|
```
|
|
{
|
|
"kind": 5,
|
|
"pubkey": <32-bytes hex-encoded public key of the event creator>,
|
|
"tags": [
|
|
["e", "dcd59..464a2"],
|
|
["e", "968c5..ad7a4"],
|
|
["a", "<kind>:<pubkey>:<d-identifier>"],
|
|
["k", "1"],
|
|
["k", "30023"]
|
|
],
|
|
"content": "these posts were published by accident",
|
|
...other fields
|
|
}
|
|
```
|
|
|
|
Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the retraction request. Clients SHOULD hide or otherwise indicate a retraction status for referenced events.
|
|
|
|
Relays SHOULD continue to publish/share the retraction events indefinitely, as clients may already have the event that's intended to be retracted. Additionally, clients SHOULD broadcast retraction events to other relays which don't have it.
|
|
|
|
When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the retraction event.
|
|
|
|
## Client Usage
|
|
|
|
Clients MAY choose to fully hide any events that are referenced by valid retraction 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 retracted events' own content, although a user interface should clearly indicate that this is a retraction reason, not the original content.
|
|
|
|
A client MUST validate that each event `pubkey` referenced in the `e` tag of the retraction request is identical to the retraction 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 retraction event itself in any way they choose, e.g., not at all, or with a prominent notice.
|
|
|
|
Clients MAY choose to inform the user that their request for retraction does not guarantee deletion because it is impossible to delete events from all relays and clients.
|
|
|
|
## Relay Usage
|
|
|
|
Relays MAY validate that a retraction event only references events that have the same `pubkey` as the retraction itself, however this is not required since relays may not have knowledge of all referenced events.
|
|
|
|
## Retracting a Retraction
|
|
|
|
Publishing a retraction event against a retraction has no effect. Clients and relays are not obliged to support "unretract" functionality.
|