mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-13 23:39:08 -05:00
52 lines
1.8 KiB
Markdown
52 lines
1.8 KiB
Markdown
|
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
|