nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-20 06:45:49 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Adds clarification that kind18 alone cannot be trusted

Browse Source 
Adds clarification that this requires web of trust validation
Adds k-tag to generic reposts
Adds optional behavior to client.
This commit is contained in:
Vitor Pamplona 2024-02-17 17:50:50 -05:00
parent 5ec1bd96f5
commit 1e888d99cc
1 changed files with 11 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
22.md
View File

@ -19,7 +19,9 @@ Kind 18 informs the network that the owner of the pubkey is migrating to a new k
}
```
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.
`Kind:18`s 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
@ -31,9 +33,13 @@ There can be multiple `kind:18`s pointing to separate keys. Finding which event
## Information retention
Supporting Relays and Clients MUST reject Event Deletion ([NIP-09](09.md)) requests of `kind:18`s.
Clients SHOULD send `kind:18` to as many relays as possible, not only to the owner's relay list.
Clients SHOULD use Generic Repost (`kind:16`) with a stringified version of the `kind:18` to warn followers and guarantee its retention in as many relays as possible.
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
@ -43,6 +49,8 @@ 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.
It's ok to delay verification until trusted keys start informing their assessments.
Upon verification, Clients SHOULD offer transition to the new key by: