New NIP to lock user

100.md

@@ -0,0 +1,78 @@
+
+NIP-100
+======
+
+Lock user
+-------------
+
+`draft` `optional`
+
+### Abstract
+
+In Nostr, users are defined by a pair of public and private keys. These keys are what allow the user to be identified (through the known public key) and ensure that the content is published by the owner of the key pair (through signing with the private key).
+
+This cryptography-based mechanism is very robust and secure, but it is not immune to being attacked. One of the main attack vectors is the theft of the private key itself.
+
+Unlike other protocols like Bitcoin, the theft of a private key does not imply a direct theft of the user's assets, but it can have other implications such as identity theft and consequent fraud attempts. This has a special impact when the stolen key belongs to a highly relevant user.
+
+Although there are currently mechanisms to protect and safeguard our keys, this does not provide complete reliability, and they can always be stolen. To try to mitigate the impact of this problem, this NIP provides a mechanism by which once the key owner suspects or has certainty that the keys have been stolen, they can lock their user and thus prevent (or at least partially prevent) events from being emitted in their name.
+
+### User Lock Event
+
+#### Field `kind`
+
+The `kind:1000` event is defined, which will be sent to the Relays and will indicate that this user should be locked.
+
+#### Field `pubkey`
+
+This is the public key of the event signer and the corresponding public key associated with the stolen private key that wants to be locked.
+
+#### 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.
+
+##### Example
+
+```json
+{
+  "kind": 1000,
+  "pubkey": <pubkey to be locked>,  
+  "content": "Someone has stolen my password",
+  ...
+}
+```
+### 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.
+
+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.
+
+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.
+
+#### Optional
+
+Optionally, clients CAN prevent the sending of events signed by a locked user, as well as decrypt direct encrypted messages using [NIP-04](./04.md) or [NIP-17](./17.md).
+
+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-59 Usage
+
+The operation of the Relays and C
+lients in the event of receiving an event using [NIP-59](./59.md) will be the same as described in the previous sections, except that the signer of the `seal` event (`kind:13`) will be used to validate whether the event should be accepted (in the case of Relays) or hidden/marked (in the case of Clients).
+
+### 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.
+2. It is possible that the thief of the key may continue to emit events in the name of the affected user by sending them to Relays that do not implement this NIP. However, these will not be replicated to Relays that do implement them. Eventually, users will tend to use Relays that implement this NIP since they provide more security and reliability.
+3. Although events continue to be retransmitted to Relays that do not implement this NIP, using clients that do implement it provides reliability in the event query.
+4. It is up to the clients to decide how to handle the events of a locked user. They can hide them, mark them in some way, or even allow the user to configure how these events are handled.
+5. The process proposed in this NIP implies that in the event of key theft, the thief can lock the user before the legitimate key owner does. This is assumed since the main problem in the event of Nostr key theft is identity theft, and not so much the ability to continue using them.
+6. As explained for NIP-59, any future NIP developed where the signature is not made by the event author, the control performed by Relays and clients should keep it in mind.

README.md

@@ -87,6 +87,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
+- [NIP-100: Lock User](100.md)
 
 ## Event Kinds
 
@@ -114,6 +115,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `43`          | Channel Hide Message            | [28](28.md)                            |
 | `44`          | Channel Mute User               | [28](28.md)                            |
 | `818`         | Merge Requests                  | [54](54.md)                            |
+| `1000`        | Lock User                       | [100](100.md)                          |
 | `1021`        | Bid                             | [15](15.md)                            |
 | `1022`        | Bid confirmation                | [15](15.md)                            |
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |