mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-04-01 16:38:46 +02:00
Merge 4768ab47f0bbf14491c200fc8c11f512f43676e7 into 2a4c44035e56580fb22929972a69280236663557
This commit is contained in:
commit
e6f91f5d16
79
66.md
Normal file
79
66.md
Normal file
@ -0,0 +1,79 @@
|
||||
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.
|
@ -35,6 +35,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|
||||
- [NIP-56: Reporting](56.md)
|
||||
- [NIP-57: Lightning Zaps](57.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-66: Decimate](66.md)
|
||||
|
||||
## Event Kinds
|
||||
| kind | description | NIP |
|
||||
@ -46,6 +47,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|
||||
| 4 | Encrypted Direct Messages | [4](04.md) |
|
||||
| 5 | Event Deletion | [9](09.md) |
|
||||
| 7 | Reaction | [25](25.md) |
|
||||
| 10 | Decimate | [66](66.md) |
|
||||
| 40 | Channel Creation | [28](28.md) |
|
||||
| 41 | Channel Metadata | [28](28.md) |
|
||||
| 42 | Channel Message | [28](28.md) |
|
||||
|
Loading…
x
Reference in New Issue
Block a user