nostr
/
nips
mirror of https://github.com/nostr-protocol/nips.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

slightly improving text

This commit is contained in:
Vitor Pamplona 2024-02-18 12:25:33 -05:00
parent c78e79e9cd
commit 531ab70a4d
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
22.md
View File

@ -23,7 +23,7 @@ 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 and this event might come from an attacker, `Kind:18`s **alone** can't be trusted.
Since the owner's keys might have leaked and `kind:18`s might come from attackers, `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.
@ -43,9 +43,9 @@ Clients SHOULD send `kind:18` to as many relays as possible, not only to the own
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.
Clients SHOULD use Generic Reposts (`kind:16`) to warn followers and improve `kind:18`'s retention on relays. Generic Reposts MUST include a JSON-stringified version of the `kind:18` in its `.content` and a `k`-tag set to `18`
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.
Generic Repost events MUST NOT be considered a user's final decision on which key to switch to. Contact lists are the only source of confirmation.
## Client Behavior