nips/704.md

NIP-704
======

Key derivation for Encrypted Direct Messages
-----------------------------------

`draft` `optional` `author:motorina0`

This NIP defines a way for two clients to derive `one-use-only` keys for sending and recieving `kind:4` events.

## Motivation
The content of `Direct Messages` [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) is encrypted, but everyone can see who is chatting with whom. This is far from ideal from a privacy perspective. 

This NIP describes a way to obfuscate DM communications from the "general public", it does not deal with the relay tracking of clients (for that see [NIP XXX](xxx)).

## Suggestion
For the maximum of privacy the two participants of a `Direct Message` exchange SHOULD use a different public key for **each** `kind:4` event.
This means that each participant has to:
 - build a `direct message parent key` from which it will derive keys to send and keys to recieve (listen for) `kind:4` events
 - share this `direct message parent key` with its DM peer

Each client has a `master` key (denoted with `m`). This key can be the profile `nsec...`, but it is not mandatory.

## Deriving the direct message parent key
[BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) is used to derive the paths. A client can generate multiple `direct message parent keys`, one for each peer that it is communicating with. Nostr `coin_type'` is `1237'` (see [NIP-06](https://github.com/nostr-protocol/nips/blob/master/06.md)). In this NIP we define the purpose `25709'` (`dm` -> `0x646d` -> `25709`) for deriving `Direct Messages` related keys.
 
 
 When client `Alice` wants to build its `dm parent key` for `Bob` it has to:
  - get the public key of `Bob` (in hex). Eg: `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d`.
  - split the public key hex string in 8 chunks:
       - `3bf0c63f`, `cb934634`, `07af97a5`, `e5ee64fa`, `883d107e`, `f9e55847`, `2c4eb9aa`, `aefa459d`
  - derive the `dm parent key`: `m/25709'/1237'/p1'/p2'/.../p8'`

> **Note** the reason for using the peer's public key (`Bob`) in the `dm parent key` derivation is to always arive at the same value even if prio state is lost.
> 
> **Note** the reason for splitting is that each level of the path can have a max value of 2<sup>32</sup>-1.