Simple key rotation procedure with web of trust.

22.md

@@ -0,0 +1,51 @@
+NIP-22
+======
+
+Key Rotation
+------------
+
+`draft` `optional`
+
+Kind 18 informs the network that the owner of the pubkey is migrating to a new key. The event MUST contain a single `p` tag with the new pubkey to be used to communicate with the owner. 
+
+```js
+{
+  "kind": 18,
+  "tags": [
+    ["p", "<pubkey>", "<relay_url>"],
+  ],
+  "content": "<comment to followers>"
+  //...
+}
+```
+
+Close acquaintances to the owner should verify the intention off-nostr and signal their assessment of the request's accuracy by following the new key. 
+
+## 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.
+
+Users that have a `kind:18` published by their keys MUST migrate to a new key. 
+
+There can be multiple `kind:18`s pointing to separate keys. Finding which event is the right one requires observing contact lists of trusted keys.
+
+## Information retention
+
+Supporting Relays and Clients MUST NOT accept Event Deletion ([NIP-09](09.md)) requests of `kind:18`s.
+
+Clients SHOULD use Generic Repost (`kind:16`) with a stringified version of the `kind:18` to guarantee its retention in as many relays as possible. 
+
+## Client Behavior
+
+Upon receiving a new `kind:18`, Clients MUST warn their user the pubkey is unsafe. 
+
+Clients SHOULD offer ways to investigate and verify if: 
+1. the transition to a new key was intended by the owner OR 
+2. if this is an attack and the new key is controlled by an attacker.
+
+It's ok to delay verification until trusted keys start informing their assessments.
+
+Upon verification, Clients SHOULD offer transition to the new key by: 
+1. Changing the contact list accordingly
+2. Changing any NIP-51 list accordingly 
+3. Adding the key to the Mute List