nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-21 16:15:51 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

deleting-replaceables

Browse Source
This commit is contained in:
fiatjaf 2024-05-27 10:41:14 -03:00
parent 85df9b0e89
commit 0535f01508
1 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
09.md
View File

@ -14,14 +14,13 @@ The event's `content` field MAY contain a text note describing the reason for th
For example:
```
```jsonc
{
"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>"]
],
"content": "these posts were published by accident",
...other fields
@ -34,9 +33,9 @@ Relays SHOULD continue to publish/share the deletion events indefinitely, as cli
## 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.
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.
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.
@ -46,4 +45,10 @@ Relays MAY validate that a deletion event only references events that have the s
## 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. Clients and relays are not obliged to support "undelete" functionality.
## Deleting Replaceable Events
Because of their changing nature it's hard to get rid of all instance of a replaceable event (ranges `10000...19999` and `30000...39999`). We also don't want to publish a `kind:5` targeting an `a` reference and thus permanently delete any future events that could possibly have the same specifieds `kind` and `d`-tag forever.
So instead to delete a replaceable event we **overwrite** it with an event with the same `kind` and `d`-tag, plus a tag `["deleted"]` specifying no other tags.