The kind of the event is changed to 398

This commit is contained in:
Anurag Lint 2024-09-09 10:53:16 +02:00
parent abcafd3c80
commit 290792d7e7

12
100.md
View File

@ -21,7 +21,7 @@ Although there are currently mechanisms to protect and safeguard our keys, this
#### Field `kind`
The `kind:1000` event is defined, which will be sent to the Relays and will indicate that this user should be locked.
The `kind:398` event is defined, which will be sent to the Relays and will indicate that this user should be locked.
#### Field `pubkey`
@ -35,7 +35,7 @@ The `content` field must be empty to prevent the attacker from publishing a mali
```json
{
"kind": 1000,
"kind": 398,
"pubkey": <pubkey to be locked>,
"content": "",
...
@ -43,17 +43,17 @@ The `content` field must be empty to prevent the attacker from publishing a mali
```
### Relay Usage
Relays that implement this NIP, once they receive the `1000` type event, MUST NOT accept any other event issued by the user who has been locked.
Relays that implement this NIP, once they receive the `398` type event, MUST NOT accept any other event issued by the user who has been locked.
Previous events CAN still be queried, but NO operations on them, such as deletion ([NIP-09](./09.md)) or replacement (in the case of replaceable events), will be allowed.
### Client Usage
To lock a user, clients will have an option that allows performing this action. This action will emit a `kind:1000` event signed with the private key that is to be locked.
To lock a user, clients will have an option that allows performing this action. This action will emit a `kind:398` event signed with the private key that is to be 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.
Clients that implement this NIP MUST check if a `kind:398` 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 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.
Optionally, clients CAN display the `398` 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