NIP-21

Non-public encrypted messages

draft optional author:fiatjaf

This NIP defines a method for relays to verify the identity of the client that is requesting "encrypted directed messages" and only allow these clients to see messages authored by them or intended for them.

When connecting to relays that support this NIP, clients SHOULD send an event of kind 20001, meaning "client identification", with the content set to "client identification for <relay hostname>".

The relay MUST then use the event to verify the identity of the client and discard it afterwards. In the verification process the relay MUST check:

if event signature is valid;
if the content phrase matches the canonical phrase with the actual relay hostname in it;
if the event timestamp is not too far from the relay's current timestamp.

If all is well, then the relay can use the identified pubkey to validate further requests for kind-4 events and only return kind-4 events that were either authored by the identified pubkey ("pubkey": ...) or are addressed to the identified pubkey ("tags": ["p", ...]).

Example

Client connects to wss://chat.relay.nostr.com/
Client sends ["EVENT", {"id": "...", "pubkey": "aeae...", "sig": "...", "kind": 20001, "tags": [], "created_at": 1609470000, "content": "client identification for chat.relay.nostr.com"}]
Client sends ["REQ", "my-dms", {"kinds": [4], "#p": ["aeae..."]}, {"kinds": [4],"authors": ["aeae"]}]
Relay sends ["EVENT", "my-dms", {"id": "...", "pubkey": "aeae...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "786b..."]}]
Relay sends ["EVENT", "my-dms", {"id": "...", "pubkey": "786b...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "aeae..."]}]

Ids and signatures omitted and pubkeys shortened for readability.

Rationale

NIP-04 is flawed because its event contents are encrypted, but the metadata around it is not, and by the nature of Nostr as a protocol designed for public communication in general anyone is able to query relays for any event they want -- thus it's possible to anyone to track conversations between any other Nostr users, not exactly what they're saying, but to whom they're chatting and how often.

Thus it's ironic that an end-to-end encrypted messaging protocol (such as NIP-04) turns out to be less private then a not end-to-end encrypted messaging protocol (such as Telegram).

Telegram and other widely used direct messaging apps are generally trusted not only to not reveal metatada, but also to not reveal the contents of the messages, to which they have direct access.

Other messaging services, deemed more private, such as Signal, do not have the contents of the conversations as these are end-to-end encrypted, but do have the metadata, and are trusted to not reveal that.

This NIP, if used in conjunction with relays that are trusted to honor it and not leak private data, makes it so Nostr direct messaging is strictly superior to Telegram¹ and on par with Signal².

Comparison with other proposals

Over the last months a number of other proposals were made to try to improve the lack of privacy NIP-04 provides³⁴⁵.

Although all these proposals solve the issue in some way of another, and it can be argued they are superior to the current (although that can be disputed⁶⁷), they generally have two shortcomings:

They add a lot of complexity: NIP-04 is very simple and direct, these other proposals are much more involved. More complexity means less clients and less decentralization.
They are incompatible with the broader Nostr identity scheme: one of the important strengths of Nostr is the ability of relays to identify the authors of events and decide if they are spammers or not, and if they want to store and relay these events or not these or not (for example, based on payment or some other form of registration). Ephemeral public keys or key aliases break these, or at least make them much harder to implement on the relay and client sides, which brings us back to point 1.

Further possibilities

Some random things that can be optionally done based on this NIP:

If relays can now get the public key of a client that is using it for direct messages, it can also give read reports to the ones who sent the messages (because it will know when the other side of the conversation have requested and received each message in the chat). This is a UX improvement that can't be achieved otherwise.
Clients can obfuscate the global view relays would have from their metadata by using multiple relays and only sending direct messages to one (or a few) at a time. Thus, if two peers share relays A and B, they can send 50% of the messages through relay A and 50% through relay B.

These possibilities can be specified better on further NIPs.

Not considering, of course, the million other features Telegram offers, that are irrelevant to this document. ↩︎
Not considering, of course, the cryptographic protocols that Signal uses to provide forward secrecy and other advanced functionality which are already not present in NIP-04. ↩︎
https://github.com/nostr-protocol/nostr/issues/69 ↩︎
https://github.com/nostr-protocol/nostr/pull/71/files ↩︎
https://github.com/nostr-protocol/nips/pull/17 ↩︎
For example, even with ephemeral keys, if the general public still have access to all the events some time-analyses and other heuristics can be used to try to track chat activity between Nostr users. ↩︎
Another example: even with ephemeral keys, it can be assumed that relays will know at least the IP address of the clients that are using it for the kind-4 messages, so they will have almost as much metadata as before -- which brings us back, again, to some level of trust on these relays to not reveal this metadata to the public, as in the current proposal. ↩︎

5.8 KiB Raw Blame History