From 1f123fe12eeca0a0eeb12d53592b27d4398c2760 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Sat, 17 Feb 2024 18:10:37 -0500 Subject: [PATCH] minor adjustments 2 --- 22.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/22.md b/22.md index 68891c4a..4570993d 100644 --- a/22.md +++ b/22.md @@ -45,21 +45,17 @@ Relays and Clients MUST reject Event Deletion ([NIP-09](09.md)) requests of `kin 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. +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 confirmation. ## 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. +Clients MAY download follow lists of follows and display when a follow has switched to a new key. -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 confirmation until trusted keys start informing their assessments. -It's ok to delay verification until trusted keys start informing their assessments. - -Upon verification, Clients SHOULD offer transition to the new key by: +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