Add NIP66 draft - Decimate

66.md

@@ -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.

README.md

@@ -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)             |