mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-09-20 06:45:49 -04:00
Add NIP66 draft - Decimate
This commit is contained in:
parent
b1a5ad355a
commit
4768ab47f0
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-56: Reporting](56.md)
|
||||||
- [NIP-57: Lightning Zaps](57.md)
|
- [NIP-57: Lightning Zaps](57.md)
|
||||||
- [NIP-65: Relay List Metadata](65.md)
|
- [NIP-65: Relay List Metadata](65.md)
|
||||||
|
- [NIP-66: Decimate](66.md)
|
||||||
|
|
||||||
## Event Kinds
|
## Event Kinds
|
||||||
| kind | description | NIP |
|
| 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) |
|
| 4 | Encrypted Direct Messages | [4](04.md) |
|
||||||
| 5 | Event Deletion | [9](09.md) |
|
| 5 | Event Deletion | [9](09.md) |
|
||||||
| 7 | Reaction | [25](25.md) |
|
| 7 | Reaction | [25](25.md) |
|
||||||
|
| 10 | Decimate | [66](66.md) |
|
||||||
| 40 | Channel Creation | [28](28.md) |
|
| 40 | Channel Creation | [28](28.md) |
|
||||||
| 41 | Channel Metadata | [28](28.md) |
|
| 41 | Channel Metadata | [28](28.md) |
|
||||||
| 42 | Channel Message | [28](28.md) |
|
| 42 | Channel Message | [28](28.md) |
|
||||||
|
|
Loading…
Reference in New Issue
Block a user