From 149f7c140dc16be8a7aa0c7b9f4c87ee9d731c0a Mon Sep 17 00:00:00 2001
From: Vlad Stan <stan.v.vlad@gmail.com>
Date: Mon, 10 Apr 2023 11:23:04 +0300
Subject: [PATCH] doc: update exchange

---
 704.md | 34 ++++++++++++++++++++++++++++++++--
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/704.md b/704.md
index 3db576c..1455d22 100644
--- a/704.md
+++ b/704.md
@@ -16,12 +16,12 @@ This NIP describes a way to obfuscate DM communications from the "general public
 ## 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
+ - build a `direct message parent key` from which it will derive keys to send and keys to receive (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
+## Derive 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.
  
  
@@ -34,3 +34,33 @@ Each client has a `master` key (denoted with `m`). This key can be the profile `
 > **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.
+
+dm/<action>/index
+ send, receive, marketplace
+
+## Exchange the `direct message parent key`
+If `Alice` wants to signal `Bob` that she is ready to use this NIP (for more privacy) she must:
+ - build a JSON data of the form:
+```json
+ {
+  "key": <the direct message parent key>,
+  "send_index": <integer (optional), ...>,
+  "receive_index": <integer (optional), ...>,
+ }
+ ```
+ - publish a `Parameterized Replaceable Event` ([NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md)) having:
+
+```json
+ {
+  ...
+  "kind": 35709,
+  "content": <NIP-04 encrypted content of the JSON data>,
+  "tags:" [
+    "d": <sha256 of the shared secret as defined in NIP-04>
+  ]
+ }
+```
+ 
+ > **Note** the reason for using `sha256(shared_secret)` for the `d` tag is so that outside observers do not even know that `Alice` and `Bob` have started to communicate. Any other value for the `d` tag would reveal that the message is intended for `Bob.`
+ 
+ After both `Alice` and `Bob` have published the `kind: 35709` event, they start to publish and listen to events using the `one-use-keys`.