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:398 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 must be empty to prevent the attacker from publishing a malicious message that could result in a new attack vector.

Example

{
  "kind": 398,
  "pubkey": <pubkey to be locked>,  
  "content": "",
  ...
}

Relay Usage

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) 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:398 event signed with the private key that is to be 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 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

Optionally, clients CAN prevent the sending of events signed by a locked user, as well as decrypt direct encrypted messages using NIP-04 or NIP-17.

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) 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

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.
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.
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.
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.
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.

5.1 KiB Raw Blame History