nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 08:55:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

minor adjustments 2

Browse Source
This commit is contained in:
Vitor Pamplona 2024-02-17 18:10:37 -05:00
parent f91d82425b
commit 1f123fe12e
1 changed files with 4 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
22.md
View File

@ -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