Add "z" as authorized deletion pubkey tag

09.md

@@ -28,21 +28,25 @@ For example:
 }
 ```
 
-Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request.  Clients SHOULD hide or otherwise indicate a deletion status for referenced events.
+Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request.
+When a referenced event contains `z` tags(s), however, **instead of the former rule**, relays SHOULD only honor
+deletion requests with a `pubkey` that matches one of the `z` tags values.
+
+Clients SHOULD hide or otherwise indicate a deletion status for referenced events.
 
 Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it.
 
 ## Client Usage
 
 Clients MAY choose to fully hide any events that are referenced by valid deletion 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 reason, not the original content.
 
-A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event.  Relays can not, in general, perform this validation and should not be treated as authoritative.
+A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey` OR that each referenced event has `z` tag value equal to the deletion request `pubkey` before hiding or deleting any event.  Relays can not, in general, perform this validation and should not be treated as authoritative.
 
 Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice.
 
 ## Relay Usage
 
-Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself, however this is not required since relays may not have knowledge of all referenced events.
+Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself OR that have a `z` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events.
 
 ## Deleting a Deletion
 

README.md

@@ -197,6 +197,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `r`               | a reference (URL, etc)               | petname              |                                       |
 | `r`               | relay url                            | marker               | [65](65.md)                           |
 | `t`               | hashtag                              | --                   |                                       |
+| `z`               | authorized deletion pubkey (hex)     | --                   | [09](09.md)                           |
 | `alt`             | summary                              | --                   | [31](31.md)                           |
 | `amount`          | millisatoshis, stringified           | --                   | [57](57.md)                           |
 | `bolt11`          | `bolt11` invoice                     | --                   | [57](57.md)                           |