nip09: filtered deletation.

09.md

@@ -6,7 +6,7 @@ Event Deletion Request
 
 `draft` `optional`
 
-A special event with kind `5`, meaning "deletion request" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being requested for deletion.
+A special event with kind `5`, meaning "deletion request" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author requests to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being requested for deletion.
 
 The event's `content` field MAY contain a text note describing the reason for the deletion request.
 
@@ -34,6 +34,31 @@ Relays SHOULD continue to publish/share the deletion request events indefinitely
 
 When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion request event.
 
+## Filter Deletation
+
+A client MAY use `f` tag to provide a filter, relays and clients SHOULD consider deletation of all events matching to this specific filter from this client up to `kind 5` created at.
+
+For example:
+```jsonc
+{
+  "kind": 5,
+  "pubkey": <32-bytes hex-encoded public key of the event creator>,
+  "tags": [
+    ["f", "{\"kinds\":[1,7]}"]
+  ],
+  "content": "no more text note and reactions.",
+  // other fields...
+}
+```
+
+The above event requests the deletation of all text notes and reactions from a user.
+
+A kind 5 MUST NOT contain a `f` tag beside other tags, or multiple `f` tags in one event. The `"authors"` field of the filter should be implicit.
+
+### Usages
+
+User can make complex bulk deletation requests with consuming small space and this bring possiblited to remove ***all posts***, ***direct messages***, or ***delete account***.
+
 ## Client Usage
 
 Clients MAY choose to fully hide any events that are referenced by valid deletion request 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 request reason, not the original content.
@@ -51,3 +76,7 @@ Relays MAY validate that a deletion request event only references events that ha
 ## Deletion Request of a Deletion Request
 
 Publishing a deletion request event against a deletion request has no effect.  Clients and relays are not obliged to support "unrequest deletion" functionality.
+
+## Protection for a Deletion Request
+
+if the deletion request is intended to be applied in a set of limited relays, clients can send them as protected events and expect other relays to not execute them in sync or broadcasting.

README.md

@@ -248,6 +248,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | name              | value                                | other parameters                | NIP                                   |
 | ----------------- | ------------------------------------ | ------------------------------- | ------------------------------------- |
 | `e`               | event id (hex)                       | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md)              |
+| `f`               | stringified filter object            |                                 | [09](09.md)                           |
 | `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md)              |
 | `a`               | coordinates to an event              | relay URL                       | [01](01.md)                           |
 | `d`               | identifier                           | --                              | [01](01.md)                           |