diff --git a/704.md b/704.md
index 976eed6..06feb2a 100644
--- a/704.md
+++ b/704.md
@@ -11,18 +11,18 @@ This NIP defines a way for two clients to derive `one-use-only` keys for sending
 ## 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. Privacy wise this is far from ideal.
 
-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-705]([xxx](https://github.com/motorina0/nips/blob/republish_events/705.md))).
+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-705](https://github.com/motorina0/nips/blob/republish_events/705.md)).
 
 ## 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 receive (listen for) `kind:4` events
- - share this `direct message parent key` with its DM peer
+ - 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.
 
-## Derive the `direct message parent key`
-A client must generate multiple `direct message parent keys`, one for each peer that it is communicating with. The [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) structure to be used is:
+## Derive the `direct-message parent key`
+A client must generate multiple `direct-message parent keys`, one for each peer that it is communicating with. The [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) structure to be used is:
 ```
 m / purpose' / conin_type' / part1' / part2' / ... / part8'
 ```
@@ -45,7 +45,7 @@ If Alice wants to build he <code>dm parent key</code> for Bob then she has to:
  </ul>
 </details>
 
-We notate the above derived `direct message public key` with  `dmpk`. Then we can define paths of the form `dmpk/<action>/index`.
+We notate the above derived `direct-message public key` with  `dmpk`. Then we can define paths of the form `dmpk/<action>/index`.
 
 | Action Name           | Value  | Path                | Derive keys for                   |
 |-----------------------|--------|---------------------|-----------------------------------|
@@ -58,12 +58,12 @@ The client (creator of the `dmpk`) must:
  - use a new send key (`dmpk/0/<index>`) for each event it signs. It starts from `0` and increments after an event is signed.
  - create filters for the public keys it expects to receive messages to (`dmpk/1/<index>`). It is recommended to listen for the next `10` keys and increment the index once a key is used (see [BIP-44 address gap logic](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#user-content-Address_gap_limit)).
 
-## Exchange the `direct message parent key`
+## 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 (dmpk)>,
+  "key": <the direct-message parent key (dmpk)>,
   "send_index": <integer (optional), the index of the last key used to sign an event>,
   "receive_index": <integer (optional), the index of the last key an event was received to>,
  }