Update 103.md

This commit is contained in:
threeseries 2023-05-10 19:51:23 -05:00 committed by GitHub
parent 282f3c1ab8
commit 2ce12d6709
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

54
103.md
View File

@ -1,57 +1,25 @@
NIP-103 NIP-103
======= =======
Direct Message Envelopes Onion Routed Direct Messages
------------------------ ----------------------------
`draft` `optional` `author:threeseries` `draft` `optional` `author:threeseries` `author:giszmo`
This NIP defines a kind 16 event which is a kind 4 event (see [NIP-04](04.md) where the decrypted content is itself a kind 4 event. This NIP defines event kinds 174 and 20174 which are events whose RSA-encrypted content is either a kind 4, (see [NIP-04](04.md), kind 174, or kind 20174 event. A kind 20174 event is nothing more than an ephemeral kind 174 event (kind 20174 can be substituted anywhere kind 174 appears in what follows). These events are intended as direct messages that can be routed through a network of bots or ordinary users to obscure sender and receiver.
# Motivation and usage # Motivation and usage
It's well-known that direct message metadata is public on nostr since everyone can see who is messaging whom and when. One solution to this problem is for the entire event including its metadata to be encrypted before being sent. This outer event can be encrypted and signed with a random key pair, thus hiding the true sender of the direct message. Despite being encrypted direct messages on nostr have very poor privacy properties since anyone can see who is messaging whom and when. One solution to this problem is for the entire event including its metadata to be encrypted before being sent, and for the final recipient to be further obfuscated by adding additional hops between sender and receiver. In order to provide additional privacy for users RSA keys are used for encryption since these messages can be decrypted without knowledge of the encrypting user's nostr pubkey.
Alternatively, one can encrypt the kind 16 with one's own key pair and send to an intermediate pubkey which is responsible for forwarding the message on to the final recipient. This too would provide anonymity as long as the intermediate pubkey is receiving messages from different users, and effort is made to remove correlation based on timing. The flow works as follows: when Bob wishes to send Alice an onion-routed DM he must first identify a set of intermediate pubkeys that can be used for routing and obtain their corresponding RSA public keys. Once done Bob creates a kind 4 event addressed to Alice using his nsec and then encrypts the whole event JSON using Alice's public RSA key. This becomes the content for the outer kind 174 event. The sender of this outer event is not Bob in general, but is rather the pubkey immediately before Alice in the chain. Events are then iterately wrapped in kind 174, working back up the chain until finally reaching Bob.
On receiving a kind 16 event the client should decrypt both the outer and inner content, displaying the decrypted inner content to the recipient. When Bob sends this kind 174 event to the first hop in the chain, the user or bot decrypts the content using their private RSA key. The decrypted content will be either kind 174 or kind 4, and the message is forwarded to the recipient pubkey. In order to provide additional privacy time delays can be added, or messages not forwarded until enough are in a queue.
# Example: # Intermediate hops
A kind 4 event: Intermediate nodes can be one of two types: always-online bots that exist solely to perform onion-routing, or ordinary users who have opted into forwarding messages for others (this also provides plausible deniability to the users themselves who are participating in forwarding). In the former case it may be desirable to use kind 20174 to make tracing more difficult, however there needs to be a way for bots to signal that they're online to ensure that such a message will be received. Hence it may be useful to have an ephemeral "heartbeat" event for sending these types of signals.
```json # RSA keys
{
"id": "67264df8e079a7cf52f81b912debb4e47550743f1f4a5f170407f83bc9dbc12b",
"pubkey": "6475c0ba9c8f5f45dcfdae553189d1b8d089118295ba5b902c0a698e192f535b",
"created_at": 1682886605,
"content": "z2HVzkQXJAJSqebsnrkNWg==?iv=O0pf3XLsEkOo+G+/QosxDg==",
"kind": 4,
"tags": [
[
"p",
"208404de380e7c02c366cc667ae9e969d687ec7a3c03aacd364c4716a2e72327"
]
],
"sig": "1626034f09101c120f968ef1da14dd23e4e4b14db22227737ad717cc9033188e0426cf0993a0c776b8a5156ef6ece939f50f575ce294b9689864b46f49b5e8c6"
}
```
After wrapping in kind 16 with another key pair: RSA keys should be derived deterministically from the user's nsec. They should also be advertised in the metadata of a pubkey for any account that can perform onion-routing.
```json
{
"id": "b8b50e4c63102e5c737186e7ed7c23741aea34a7743ea27a41e6a18654261818",
"pubkey": "4c34b0fb27f79d376456f95391b1b43173d890d3e08558fe1e0f56cea59af52a",
"created_at": 1683293572,
"content": "se/NybRw+cM1gMbbjOrg0eP9GWUjJrLP5wBYI2b7CHLHjoP3fv88cycysQQWIQ7MPj5sHvLBJQaGNWWsSP9WLocRt0sZdZtXHwYhshYnpO0lvZxmkthcYqJ3b9I6pHUGcV1G4v9qSUjhvfCnHLf5vIh36XhN0aADUZppR2Yix0C/aCZIyY8xs6HJh8BQyGaDfdO2KsSNCgfxFJe2hXwGjBe9M/MnBos2Kqi3U/Z2Vhqy4tqrbthpP+/dJT4m1FhANJNCfPGrgRdvH00GOm2l/BTxA/GtSo8gOjmkC+uLxI3kNK4+Vb+SuOM5JbAzyMyc3XkxmgS9hlNAyZGyX3vbDBKxhRt0iK0kYg0pw9Gpna2rrBu8qO7khDiZKk5L/pqGrSWXnQ8RcHPkaKgsTTk4XTn5jZzfukFOG/5Zawdbl8nhtl4kYPQSU0pEXrkd89AuW7O4JRqwSXzni/NidES+vD/35RGelVtebFYGvK7TDO8A0V9hOIPKa0a7tc7TdhaUO288wlw0lEE68llzN6c8cxv411RGaSC60pk+Fnd+04rOTSJrc+qUQ3FtO79tDsLaKQhIFgJxIfZcxEaXVQksgR+X0DQTq6RDkr6h2QoIZnlRdIoXjPCSH6JTqcKuVb9l?iv=FT7fwoP8pjjE97MUO9J8nA==",
"kind": 16,
"tags": [
[
"p",
"208404de380e7c02c366cc667ae9e969d687ec7a3c03aacd364c4716a2e72327"
]
],
"sig": "ea7a1c500e2ebd3a1985777874c66d8fb21d1ae3d2ed5ed643ff7a60d42152923c5545794dac5b30d8ac51327812afb3c7c76c7616165dc92fe0040a2aa5bf12"
}
```