mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
Update 704.md
This commit is contained in:
parent
ac6d5ef2e5
commit
84db35b8c3
41
704.md
41
704.md
|
@ -6,7 +6,7 @@ More private Encrypted Direct Messages
|
||||||
|
|
||||||
`draft` `optional` `author:motorina0`
|
`draft` `optional` `author:motorina0`
|
||||||
|
|
||||||
This NIP defines a way for two clients to derive `one-use-only` keys for sending and recieving `kind:4` events.
|
This NIP defines a way for two clients to derive and share `one-use-only` keys for sending and recieving `kind:4` events.
|
||||||
|
|
||||||
## 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.
|
||||||
|
@ -16,7 +16,7 @@ This NIP describes a way to obfuscate DM communications from the "general public
|
||||||
## 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.
|
||||||
|
@ -45,44 +45,57 @@ 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 parent 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 |
|
||||||
|-----------------------|--------|---------------------|-----------------------------------|
|
|-----------------------|--------|---------------------|-----------------------------------|
|
||||||
| **send** | `0` | `dmpk/0/<index>` | sending `direct messages` |
|
| **init** | `0` | `dmpk/0/0` | initialize the `direct messages` flow|
|
||||||
| **receive** | `1` | `dmpk/1/<index>` | receiving `direct messages` |
|
| **send** | `0` | `dmpk/1/<index>` | sending `direct messages` |
|
||||||
| `draft`: republish | `2` | `dmpk/2/<index>` | sending `republish events` |
|
| **receive** | `1` | `dmpk/2/<index>` | receiving `direct messages` |
|
||||||
|
| `draft`: republish | `2` | `dmpk/3/<index>` | sending `republish events` |
|
||||||
| `draft`: market-order | `4500` | `dmpk/4500/<index>` | sending NIP45 `market orders` |
|
| `draft`: market-order | `4500` | `dmpk/4500/<index>` | sending NIP45 `market orders` |
|
||||||
|
|
||||||
The client (creator of the `dmpk`) must:
|
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/1/<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/2/<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)>,
|
"pubkey": <32-bytes lowercase hex-encoded public key of Alice (public profile key)>
|
||||||
|
"dmpk": <32-bytes lowercase hex-encoded direct-message parent key>,
|
||||||
|
"shared_secret_hash": <32-bytes lowercase hex-encoded sha256 of the shared secret>
|
||||||
"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>,
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
> **Note** `send_index` and `receive_index` are optional, but they help the client a lot in knowing what the state is. Alternatively (when an account is retored) the client would have to scan the public keys until unused ones are found (similar to [BIP-44 address gap logic](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#user-content-Address_gap_limit)).
|
> **Note** `send_index` and `receive_index` are optional, but they help the client a lot in knowing what the state is. Otherwise (when an account is retored) the client would have to scan the public keys until unused ones are found (similar to [BIP-44 address gap logic](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#user-content-Address_gap_limit)).
|
||||||
|
|
||||||
- publish a `Parameterized Replaceable Event` ([NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md)) having:
|
- publish a `Parameterized Replaceable Event` ([NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md)) of the form:
|
||||||
|
|
||||||
```json
|
```json
|
||||||
{
|
{
|
||||||
...
|
...
|
||||||
|
"pubkey": <32-bytes lowercase hex-encoded "init" public key derived using `dmpk/0/0`>,
|
||||||
"kind": 35709,
|
"kind": 35709,
|
||||||
"content": <NIP-04 encrypted content of the JSON data>,
|
"content": <NIP-04 encrypted content of the JSON data>,
|
||||||
"tags:" [
|
"tags:" [
|
||||||
"d": <sha256 of the shared secret as defined in NIP-04>
|
"d": <32-bytes lowercase hex-encoded public key of Bob>,
|
||||||
|
"p": <32-bytes lowercase hex-encoded public key of Bob>
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
> **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`.
|
If `Bob` supports this NIP then he must:
|
||||||
|
- subscribe to events for him:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"kind": 35709,
|
||||||
|
"#p": [<32-bytes lowercase hex-encoded public key of Bob>]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
- descrypt the content,
|
||||||
|
|
||||||
After both `Alice` and `Bob` have published the `kind: 35709` event, they can start to publish and listen to events using the `one-use-only` keys.
|
After both `Alice` and `Bob` have published the `kind: 35709` event, they can start to publish and listen to events using the `one-use-only` keys.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user