nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 08:55:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

clarify behaviour of kind:5 events for replaceable events

Browse Source
This commit is contained in:
Basanta Goswami 2024-02-22 16:21:31 +05:30
parent cbee1092d2
commit d26739a193
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
09.md
View File

@ -6,9 +6,9 @@ Event Deletion
`draft` `optional`
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.
A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` or `a` tags.
Each tag entry must contain an "e" event id and/or `a` tags intended for deletion.
Each `e` tag entry references the id of an event to be deleted, and each `a` tag references the co-ordinates of a (maybe parameterized) replaceable event to be deleted.
The event's `content` field MAY contain a text note describing the reason for the deletion.
@ -21,7 +21,7 @@ For example:
"tags": [
["e", "dcd59..464a2"],
["e", "968c5..ad7a4"],
["a", "<kind>:<pubkey>:<d-identifier>"]
["a", "<kind>:<pubkey>:<d-identifier (optional)>"]
],
"content": "these posts were published by accident",
...other fields
@ -32,6 +32,8 @@ Relays SHOULD delete or stop publishing any referenced events that have an ident
Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it.
In case of parameterized replaceable events, any deletion (`kind:5`) event referencing an `a` tag marks all the events using that particular `d` tag up to the point of the deletion event's `created_at`, for deletion. It is so that the same `d` tag and kind combination can be used again in the future.
## 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.