nips/22.md

66 lines
2.4 KiB
Markdown
Raw Normal View History

NIP-22
======
2024-02-16 10:12:53 -05:00
Key Migration
-------------
`draft` `optional`
2024-02-17 18:01:59 -05:00
`Kind:18` informs the network that the owner of the pubkey is migrating to a new key.
2024-02-17 17:56:33 -05:00
The event MUST contain a single `p` tag with the new pubkey owner will be using.
```js
{
2024-02-16 10:22:03 -05:00
"kind": 18,
"tags": [
["p", "<pubkey>", "<relay_url>"],
],
"content": "<comment to followers>"
//...
}
```
2024-02-17 17:56:33 -05:00
## Confirmation Chains
2024-02-17 18:01:59 -05:00
Since the owner's keys might have leaked and this event might come from an attacker, `Kind:18`s **alone** can't be trusted.
2024-02-17 17:56:33 -05:00
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.
2024-02-17 18:01:59 -05:00
Others may choose to follow suit based on their trust in such acquaintances.
## Interpretation
2024-02-17 18:01:59 -05:00
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.
2024-02-17 17:56:33 -05:00
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.
2024-02-17 18:01:59 -05:00
## 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 Repost (`kind:16`) with a stringified version of the `kind:18` and a `k` tag to `18` to let users warn followers and guarantee `kind:18`'s retention as much as possible.
Generic Re-posts events simply warn followers and MUST NOT be considered the user's final decision on which key to switch to. Contact lists are the only source of verification.
## 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.
2024-02-17 18:01:59 -05:00
Clients MAY download follow lists of the user's contact lists and display them when a follow has switched to a new key.
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
2024-02-16 10:22:03 -05:00
3. Adding the old key to the Mute List