Renaming to migration and updating the text with an improved version

22.md

@@ -1,14 +1,14 @@
 NIP-22
 ======
 
-Key Migration
--------------
+Key Revocation
+--------------
 
 `draft` `optional`
 
-`Kind:18` informs the network that the owner of the pubkey is migrating to a new key. 
+`Kind:18` informs the network that the owner of the current public key is revoking it.
 
-The event MUST contain a single `p` tag with the new pubkey owner will be using. 
+The event MUST include a single `p` tag containing the new public key the owner intends to use.
 
 ```js
 {
@@ -16,46 +16,46 @@ The event MUST contain a single `p` tag with the new pubkey owner will be using.
   "tags": [
     ["p", "<pubkey>", "<relay_url>"],
   ],
-  "content": "<comment to followers>"
+  "content": ""
   //...
 }
 ```
 
-## Confirmation Chains
-
-Since the owner's keys might have leaked and `kind:18`s might come from attackers, `kind:18`s **alone** can't be trusted. 
-
-Close acquaintances to the owner should verify the owner's intention off nostr and signal their conclusion by adding the new key to their contact lists. 
-
-Others may choose to follow suit based on their trust in such acquaintances.
-
 ## Interpretation
 
-The presence of one or more `kind:18`s, no matter who writes it, declares the key to be out of use, unreliable, unsafe, and potentially stolen: No event, past and future, from this key can be trusted anymore.  
+The presence of one or more `kind:18` events indicates that the key no longer represents the original owner. The key MUST be considered unreliable, unsafe, and potentially compromised. Consequently, no past or future events from this key, including `kind:18` events themselves, can be trusted.
 
-Users that have a `kind:18` published by their keys MUST migrate to a new key. 
+`kind:18` events may be created by the original owner or by an attacker who has taken control of the account and is attempting to redirect followers to a new key that the attacker controls.
 
-There can be multiple `kind:18`s pointing to separate new keys. Finding which event is the right one requires observing contact lists of trusted keys.
+Close acquaintances of the owner should verify the owner's new key outside of Nostr. The new key may or may not match the `p` tag in the `kind:18` event.
+
+Users whose keys have had a `kind:18` event published MUST migrate to a new key.
+
+## Confirmation Chains
+
+There may be multiple `kind:18` events pointing to different new keys. Determining the correct key requires manual verification through the account's trusted acquaintances.
+
+Trusted acquaintances SHOULD update their contact lists with the new key and inform their followers by reposting the key revocation.
+
+Others may choose to follow based on their trust in these acquaintances. The network SHOULD slowly update their records based on web of trust
 
 ## Information Retention
 
-Clients SHOULD send `kind:18` to as many relays as possible, not only to the owner's relay list.  
+Clients SHOULD broadcast `kind:18` events to as many relays as possible, not just those in the owner's relay list.
 
-Relays and Clients MUST reject Event Deletion ([NIP-09](09.md)) requests of `kind:18`s.
+Relays and Clients MUST reject Event Deletion requests for kind:18 events ([NIP-09](09.md)).
 
-Clients SHOULD use Generic Reposts (`kind:16`) to warn followers and improve `kind:18`'s retention on relays. Generic Reposts MUST include a JSON-stringified version of the `kind:18` in its `.content` and a `k`-tag set to `18`
+Clients SHOULD use Generic Reposts (`kind:16`) to warn followers and improve the retention of `kind:18` events on relays. These Generic Reposts MUST include a JSON-stringified version of the `kind:18` in the `.content` field and a `k` tag set to 18.
 
-Generic Repost events MUST NOT be considered a user's final decision on which key to switch to. Contact lists are the only source of confirmation.  
+Generic Repost events MUST NOT be considered the user's final decision on which key to switch to.
 
 ## Client Behavior
 
-Upon receiving a new `kind:18`, Clients MUST warn their user the pubkey is unsafe. 
+Upon receiving a new `kind:18` event, Clients MUST warn their users that the associated pubkey is unsafe.
 
-Clients MAY download follow lists of follows and display when a follow has switched to a new key. 
+Clients MAY use follow lists of their user's follows to display whether anyone they trust has switched to the new key.
 
-It's ok to delay confirmation until trusted keys start informing their assessments.
-
-Upon confirmation, Clients SHOULD offer transition to the new key by: 
-1. Changing the contact list accordingly
-2. Changing any NIP-51 list accordingly 
+Upon confirmation of the new key, Clients SHOULD offer a transition by:
+1. Updating the contact list accordingly
+2. Adjusting any NIP-51 lists accordingly
 3. Adding the old key to the Mute List