From ac6d5ef2e594e912fcf3071203573d175fbc4e7d Mon Sep 17 00:00:00 2001 From: Vlad Stan Date: Mon, 10 Apr 2023 16:11:56 +0300 Subject: [PATCH] doc: re-wrding --- 704.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) 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 dm parent key for Bob then she has to: -We notate the above derived `direct message public key` with `dmpk`. Then we can define paths of the form `dmpk//index`. +We notate the above derived `direct-message public key` with `dmpk`. Then we can define paths of the form `dmpk//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/`) 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/`). 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": , + "key": , "send_index": , "receive_index": , }