Update NIP-09 to rename deletion to retraction

09.md

@@ -1,14 +1,14 @@
 NIP-09
 ======
 
-Event Deletion
+Event Retraction
 --------------
 
 `draft` `optional`
 
-A special event with kind `5`, meaning "deletion" 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 deleted.
+A special event with kind `5`, meaning "retraction" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be retracted. Retraction requests SHOULD include a `k` tag for the kind of each event being retracted.
 
-The event's `content` field MAY contain a text note describing the reason for the deletion.
+The event's `content` field MAY contain a text note describing the reason for the retraction.
 
 For example:
 
@@ -28,24 +28,26 @@ 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 retraction request.  Clients SHOULD hide or otherwise indicate a retraction 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.
+Relays SHOULD continue to publish/share the retraction events indefinitely, as clients may already have the event that's intended to be retracted. Additionally, clients SHOULD broadcast retraction events to other relays which don't have it.
 
-When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion event.
+When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the retraction event.
 
 ## 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.
+Clients MAY choose to fully hide any events that are referenced by valid retraction 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 retracted events' own content, although a user interface should clearly indicate that this is a retraction 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 retraction request is identical to the retraction 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.
+Clients display the retraction event itself in any way they choose, e.g., not at all, or with a prominent notice.
+
+Clients MAY choose to inform the user that their request for retraction does not guarantee deletion because it is impossible to delete events from all relays and clients.
 
 ## 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 retraction event only references events that have the same `pubkey` as the retraction itself, however this is not required since relays may not have knowledge of all referenced events.
 
-## Deleting a Deletion
+## Retracting a Retraction
 
-Publishing a deletion event against a deletion has no effect.  Clients and relays are not obliged to support "undelete" functionality.
+Publishing a retraction event against a retraction has no effect.  Clients and relays are not obliged to support "unretract" functionality.

32.md

@@ -145,7 +145,7 @@ Author is labeling their note language as English using ISO-639-1.
 Other Notes
 -----------
 
-When using this NIP to bulk-label many targets at once, events may be deleted and a replacement
+When using this NIP to bulk-label many targets at once, events may be retracted using [NIP-09](09.md) and a replacement
 may be published. We have opted not to use parameterizable/replaceable events for this due to the
 complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying,
 publishers SHOULD limit labeling events to a single namespace.

34.md

@@ -53,7 +53,7 @@ An optional source of truth for the state of branches and tags in a repository.
 
 The `refs` tag may appear multiple times, or none.
 
-If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion.
+If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) retraction.
 
 The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is:
 

71.md

@@ -6,7 +6,7 @@ Video Events
 
 `draft` `optional`
 
-This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and deletable per [NIP-09](09.md).
+This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and retractable per [NIP-09](09.md).
 
 Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience.
 

72.md

@@ -62,7 +62,7 @@ An approval event MUST include one or more community `a` tags, an `e` or `a` tag
 
 The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
 
-Moderators MAY delete their approval of a post at any time using NIP 09 event deletions.
+Moderators MAY retract their approval of a post at any time using NIP 09 event retractions.
 
 ```jsonc
 {

90.md

@@ -199,7 +199,7 @@ Some service providers might choose to submit a `payment-required` as the first
 It's not up to this NIP to define how individual vending machines should choose to run their business.
 
 # Cancellation
-A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event.
+A job request might be canceled by publishing a `kind:5` retract request event tagging the job request event.
 
 # Appendix 1: Job chaining
 A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type.

README.md

@@ -30,7 +30,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-06: Basic key derivation from mnemonic seed phrase](06.md)
 - [NIP-07: `window.nostr` capability for web browsers](07.md)
 - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
-- [NIP-09: Event Deletion](09.md)
+- [NIP-09: Event Retraction](09.md)
 - [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md)
 - [NIP-11: Relay Information Document](11.md)
 - [NIP-13: Proof of Work](13.md)
@@ -99,7 +99,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `2`           | Recommend Relay                 | 01 (deprecated)                        |
 | `3`           | Follows                         | [02](02.md)                            |
 | `4`           | Encrypted Direct Messages       | [04](04.md)                            |
-| `5`           | Event Deletion                  | [09](09.md)                            |
+| `5`           | Event Retraction                | [09](09.md)                            |
 | `6`           | Repost                          | [18](18.md)                            |
 | `7`           | Reaction                        | [25](25.md)                            |
 | `8`           | Badge Award                     | [58](58.md)                            |