Update NIP-09 to rename deletion to retraction

1 files changed, 14 insertions, 12 deletions

diff --git a/09.md b/09.md
index b6aa72c..f153aba 100644
--- a/09.md
+++ b/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.