nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 08:55:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: re-wrding

Browse Source
This commit is contained in:
Vlad Stan 2023-04-10 16:11:56 +03:00 committed by GitHub
parent ef72990051
commit ac6d5ef2e5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
704.md
View File

@ -11,18 +11,18 @@ This NIP defines a way for two clients to derive `one-use-only` keys for sending
## Motivation ## 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. 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 ## 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. 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: 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 - 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 - 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. 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` ## 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: 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' 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> </ul>
</details> </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 | | 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. - 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)). - 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: 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: - build a JSON data of the form:
```json ```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>, "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>, "receive_index": <integer (optional), the index of the last key an event was received to>,
} }