nips/21.md

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"](04.md) messages and only allow these clients to see messages authored by them or targeted to them.

Relays supporting this NIP, upon receiving a `REQ` containing a filter for `kinds: [4]`, MUST reply with a challenge message in the format `["CHALLENGE", "<challenge string>"]`.

Clients must then generate an event of kind `20001`, meaning "challenge response", with the content set to `"<relay hostname> challenge for <subscription_id>: <challenge string>"`.

The relay MUST then use the event to verify the identity of the client and discard it afterwards.

If the signature matches and the event pubkey corresponds to the kind-04 filter -- i.e. the client is not requesting to see messages from other people -- the relay CAN proceed to return the events for the given subscription.

### Example

1. Client connects to `wss://chat.relay.nostr.com/`
2. Client sends `["REQ", "my-dms", {"kinds": [4], "#p": ["aeae..."]}, {"kinds": [4],"authors": ["aeae"]}]`
3. Relay sends `["CHALLENGE", "supertactic"]`
4. Client sends `["EVENT", {"id": "...", "pubkey": "aeae...", "sig": "...", "kind": 20001, "tags": [], "created_at": 1609470000, "content": "chat.relay.nostr.com challenge for my-dms: supertactic"}]`
5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "aeae", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "786b..."]}]`
5. 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.

### Clarifications

- What happens if the client asks for other stuff at the same time? So for example if you request for mutiple keys do you get mutiple challenges, if you ask for other event kinds as same time do they just come back as normal separately?[^q1]

  Relays MUST send a single challenge message and clients are expected to send a single challenge response back. If the client for any reason has more than one identity it should use two different subscriptions.

  If the filter has other clauses and is requesting other events (non kind-4) the relay SHOULD return these other events as always, and just leave out the kind-4 ones for after the challenge is completed.

  Clients MUST send kind-4 requests for a single pubkey (for each subscription), therefore relays SHOULD ignore subscription requests for kind-4 that define multiple pubkeys or no pubkeys at all.

- What if a client wants to grab only direct messages between two parties, for example with a filter like `{"kinds": [4], "authors": ["d3d3..."], "#e": ["8d8d..."]}`?

  In this case relays SHOULD check that there is only one pubkey in either `"authors"` and `"#e"` and accept any of those as the challenge response.

[^q1]: https://t.me/nostr_protocol/26059

## Rationale

[NIP-04](04.md) 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[^1] and on par with Signal[^2].

[^1]: Not considering, of course, the million other features Telegram offers, that are irrelevant to this document.
[^2]: 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.

## 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[^3][^4][^5].

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[^6][^7]), they generally have two shortcomings:

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

[^3]: https://github.com/nostr-protocol/nostr/issues/69
[^4]: https://github.com/nostr-protocol/nostr/pull/71/files
[^5]: https://github.com/nostr-protocol/nips/pull/17
[^6]: 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.
[^7]: 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.

## Further possibilities

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

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