nostr/nips

mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00

Vitor Pamplona 1e888d99cc Adds clarification that kind18 alone cannot be trusted

Adds clarification that this requires web of trust validation
Adds k-tag to generic reposts
Adds optional behavior to client.

2024-02-17 17:50:50 -05:00

2.4 KiB

Raw Blame History

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.

{
  "kind": 18,   
  "tags": [
    ["p", "<pubkey>", "<relay_url>"],
  ],
  "content": "<comment to followers>"
  //...
}

Kind:18s suggestion to move to a new key alone can't be trusted because the owner's keys might have leaked. It MUST be verified by Web of Trust.

Close acquaintances to the owner should verify the intention off nostr and signal their assessment of the owner's intentions by following the new key. Others can follow based on their individual trust on such those acquaintances.

Interpretation

The presence of one or more kind:18s, 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:18s pointing to separate 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) requests of kind:18s.

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:

the transition to a new key was intended by the owner OR
if this is an attack and the new key is controlled by an attacker.

Clients MAY download follow lists of the user's contact lists and display 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:

Changing the contact list accordingly
Changing any NIP-51 list accordingly
Adding the old key to the Mute List