nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-01-09 07:22:10 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

The 'content' field must be empty to send possible new attacks

Browse Source
This commit is contained in:
Anurag Lint 2024-08-16 13:14:22 +02:00
parent 45b863d2c3
commit 70c92a56db
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
100.md
View File

@ -29,7 +29,7 @@ This is the public key of the event signer and the corresponding public key asso
#### Field `content` #### Field `content`
The `content` field may include a description of the reason why the user wants to be locked, although it can be left empty. The `content` field must be empty to prevent the attacker from publishing a malicious message that could result in a new attack vector.
##### Example ##### Example
@ -53,7 +53,7 @@ To lock a user, clients will have an option that allows performing this action.
Clients that implement this NIP MUST check if a `kind:1000` event has been issued. If so, they MUST either hide the events of that user or indicate through some visual mechanism that the user authoring those events has been locked. Clients that implement this NIP MUST check if a `kind:1000` event has been issued. If so, they MUST either hide the events of that user or indicate through some visual mechanism that the user authoring those events has been locked.
Optionally, clients CAN display the `1000` locking event, indicating the reason included in the `content` field. If this field is empty, they can display a generic message. They can also indicate in the user's profile that the user has been locked. Optionally, clients CAN display the `1000` locking event, indicating a message that the user may have been compromised or that the user has been blocked. They can also indicate in the user's profile that the user has been locked.
#### Optional #### Optional