mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-09-20 06:45:49 -04:00
79 lines
2.9 KiB
Markdown
79 lines
2.9 KiB
Markdown
NIP-66
|
|
======
|
|
|
|
Decimate
|
|
-------------------
|
|
|
|
`draft` `optional` `author:hendore`
|
|
|
|
A destructive event with kind `10`, the decimate event (from Latin decem, meaning "ten") will delete matching events stored on the receiving relay.
|
|
|
|
The content is not used and SHOULD be an empty string.
|
|
|
|
Relays SHOULD accept new events in the future from the same pubkey, this event only effects what is currently stored on the relay at the time it was published.
|
|
|
|
Relays MAY delete the events from their database or soft delete but they SHOULD NOT emit those events in the future if soft deleted.
|
|
|
|
## Matching
|
|
|
|
Matches are based on event pubkey, relay tags and include/exclude tags.
|
|
|
|
A list of `r` tags will be used to prevent accidental deletion from a preffered relay. Any relays receiving this event that are not defined in the list of `r` tags would ignore the event.
|
|
|
|
Either an `include` or `exclude` tag must be provided but not both. The value of these tags contain a list of event kinds that should be taken into account when matching events to be removed.
|
|
|
|
## Purpose
|
|
|
|
The purpose of this NIP is to provide a way for users to retain control over the relays that store and share their events. Over time, it's likely users would find a few small sets of relays they prefer to publish to and would like to remove any/all events previously stored on relays used in the past.
|
|
|
|
This NIP paves the way for more control over a users data with the possibility of event management clients appearing to migrate / cleanup old events when switching to new preferred relays.
|
|
|
|
## Examples
|
|
|
|
Given we publish the events below to the following relays
|
|
|
|
- wss://example.relay.io
|
|
- wss://another-example.relay.io
|
|
- wss://some-new.relay.io
|
|
- wss://another-new.relay.io
|
|
- wss://one-more.relay.io
|
|
|
|
***Deleting everything except profile and preferred relay metadata***
|
|
|
|
Any events stored on the two relays listed in the `r` tags would be deleted except for events with the kind 0 or 10002. The remaining 3 relays that received the event can safely ignore it.
|
|
|
|
```json
|
|
{
|
|
"pubkey": "...........",
|
|
"kind": 10,
|
|
"tags": [
|
|
["r", "wss://example.relay.io"],
|
|
["r", "wss://another-example.relay.io"],
|
|
["exclude", [0, 10002]]
|
|
],
|
|
"content": "",
|
|
...other fields
|
|
}
|
|
```
|
|
|
|
|
|
***Deleting only notes from a single relay***
|
|
|
|
All of the users kind 1 events would be deleted on `wss://one-more.relay.io` the remaining 4 relays that received the event can safely ignore it.
|
|
|
|
```json
|
|
{
|
|
"pubkey": "...........",
|
|
"kind": 10,
|
|
"tags": [
|
|
["r", "wss://one-more.relay.io"],
|
|
["include", [1]]
|
|
],
|
|
"content": "",
|
|
...other fields
|
|
}
|
|
```
|
|
|
|
### Considerations
|
|
|
|
Some thought may need to go into rouge clients, in it's current state a bad acting client may sign and publish a decimate event to many relays. [NIP26](26.md) if widely adopted could prevent this in the future if users only give clients enough power for what the client needs rather than their root keypair. |