Change tag key to z

Author: arthurfranca

01.md

@@ -82,7 +82,7 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
     - for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
     - for a non-parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
 
-As a convention, all single-letter (only english alphabet letters: a-z, A-Z) and single-char exclamation mark key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter.
+As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter.
 
 ### Kinds
 
@@ -125,7 +125,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "ids": <a list of event ids>,
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
   "kinds": <a list of a kind numbers>,
-  "#<single-letter (a-zA-Z) or !>": <a list of tag values, for #e — a list of event ids, for #p — a list of event pubkeys etc>,
+  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of event pubkeys etc>,
   "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
   "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
   "limit": <maximum number of events relays SHOULD return in the initial query>

09.md

@@ -29,8 +29,8 @@ For example:
 ```
 
 Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request.
-When a referenced event contains `!` tags(s), however, **instead of the former rule**, relays SHOULD only honor
-deletion requests with a `pubkey` that matches one of the `!` tags values.
+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.
 
@@ -40,13 +40,13 @@ Relays SHOULD continue to publish/share the deletion events indefinitely, as cli
 
 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` OR that each referenced event has `!` 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.
+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 OR that have a `!` tag value equal to the deletion `pubkey`, 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)                           |