NIP-42 usage

This commit is contained in:
Anurag Lint 2024-10-20 13:29:33 +02:00
parent 290792d7e7
commit 4d58a56b02

11
100.md
View File

@ -61,6 +61,17 @@ Optionally, clients CAN prevent the sending of events signed by a locked user, a
For the key thief, this is easily avoidable by using another client or developing a custom one, which is why it is defined as an optional feature in this NIP. However, any difficulty in the illicit use of a key will be welcomed. For the key thief, this is easily avoidable by using another client or developing a custom one, which is why it is defined as an optional feature in this NIP. However, any difficulty in the illicit use of a key will be welcomed.
### NIP-42 Usage
Relays that support _Authentication of clients to relays_ ([NIP-42](./42.md)) must take into account that a user has been blocked when a client attempts to authenticate via the `AUTH` message. When a client attempts to authenticate by sending a `kind: 22242` event for a user that has been blocked, the relays will respond with an `OK` message indicating in the 3rd parameter the value `false`, and the 4th parameter will use the prefix `blocked`. For example:
- `["OK", "b1a649ebe8...", false, "blocked: you have been blocked"]`
Additionally, relays must close existing subscriptions for that user to prevent the client from receiving events they are no longer authorized to receive. This will be done through the `CLOSE` message, using the prefix `blocked` in the 3rd parameter.
- `["CLOSED", "sub1", "blocked: you have been blocked"]`
### Considerations ### Considerations
1. Once a user is locked, **this action is irreversible**, so the keys would remain locked in the Relays and clients that implement this NIP forever. 1. Once a user is locked, **this action is irreversible**, so the keys would remain locked in the Relays and clients that implement this NIP forever.