mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-10 06:09:08 -05:00
62 lines
2.2 KiB
Markdown
62 lines
2.2 KiB
Markdown
NIP-22
|
|
======
|
|
|
|
Key Migration
|
|
-------------
|
|
|
|
`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 owner will be using.
|
|
|
|
```js
|
|
{
|
|
"kind": 18,
|
|
"tags": [
|
|
["p", "<pubkey>", "<relay_url>"],
|
|
],
|
|
"content": "<comment to followers>"
|
|
//...
|
|
}
|
|
```
|
|
|
|
## 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.
|
|
|
|
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 new keys. Finding which event is the right one requires observing contact lists of trusted keys.
|
|
|
|
## Information Retention
|
|
|
|
Clients SHOULD send `kind:18` to as many relays as possible, not only to the owner's relay list.
|
|
|
|
Relays and Clients MUST reject Event Deletion ([NIP-09](09.md)) requests of `kind:18`s.
|
|
|
|
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`
|
|
|
|
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.
|
|
|
|
## Client Behavior
|
|
|
|
Upon receiving a new `kind:18`, Clients MUST warn their user the pubkey is unsafe.
|
|
|
|
Clients MAY download follow lists of follows and display when a follow has switched to a 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
|
|
3. Adding the old key to the Mute List
|