mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
doc: update exchange
This commit is contained in:
parent
4f266e67df
commit
149f7c140d
34
704.md
34
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`.
|
||||
|
|
Loading…
Reference in New Issue
Block a user