From d46632596a57752c3dd4b6116d3e345960b2ffb7 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Sat, 17 Feb 2024 18:01:59 -0500 Subject: [PATCH] minor adjustments --- 22.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/22.md b/22.md index 68891c4a..550aae4e 100644 --- a/22.md +++ b/22.md @@ -6,7 +6,7 @@ Key Migration `draft` `optional` -Kind 18 informs the network that the owner of the pubkey is migrating to a new key. +`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. @@ -23,21 +23,21 @@ The event MUST contain a single `p` tag with the new pubkey owner will be using. ## Confirmation Chains -Since the owner's keys might have leaked, `Kind:18`s **alone** can't be trusted. +Since the owner's keys might have leaked and this event might come from an attacker, `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 can follow based on their individual trust on such those acquaintances. +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. +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 +## Information Retention Clients SHOULD send `kind:18` to as many relays as possible, not only to the owner's relay list. @@ -55,7 +55,7 @@ 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. -Clients MAY download follow lists of the user's contact lists and display when a follow has switched to a new key. +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.