diff options
| -rw-r--r-- | 59.md | 28 |
1 files changed, 14 insertions, 14 deletions
| @@ -13,7 +13,7 @@ This NIP *does not* define any messaging protocol. Applications of this NIP shou | |||
| 13 | 13 | ||
| 14 | This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms. | 14 | This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms. |
| 15 | 15 | ||
| 16 | # Overview | 16 | ## Overview |
| 17 | 17 | ||
| 18 | This protocol uses three main concepts to protect the transmission of a target event: `rumor`s, `seal`s, and `gift wrap`s. | 18 | This protocol uses three main concepts to protect the transmission of a target event: `rumor`s, `seal`s, and `gift wrap`s. |
| 19 | 19 | ||
| @@ -29,13 +29,13 @@ This allows the isolation of concerns across layers: | |||
| 29 | - A seal identifies the author without revealing the content or the recipient. | 29 | - A seal identifies the author without revealing the content or the recipient. |
| 30 | - A gift wrap can add metadata (recipient, tags, a different author) without revealing the true author. | 30 | - A gift wrap can add metadata (recipient, tags, a different author) without revealing the true author. |
| 31 | 31 | ||
| 32 | # Protocol Description | 32 | ## Protocol Description |
| 33 | 33 | ||
| 34 | ## 1. The Rumor Event Kind | 34 | ### 1. The Rumor Event Kind |
| 35 | 35 | ||
| 36 | A `rumor` is the same thing as an unsigned event. Any event kind can be made a `rumor` by removing the signature. | 36 | A `rumor` is the same thing as an unsigned event. Any event kind can be made a `rumor` by removing the signature. |
| 37 | 37 | ||
| 38 | ## 2. The Seal Event Kind | 38 | ### 2. The Seal Event Kind |
| 39 | 39 | ||
| 40 | A `seal` is a `kind:13` event that wraps a `rumor` with the sender's regular key. The `seal` is **always** encrypted | 40 | A `seal` is a `kind:13` event that wraps a `rumor` with the sender's regular key. The `seal` is **always** encrypted |
| 41 | to a receiver's pubkey but there is no `p` tag pointing to the receiver. There is no way to know who the rumor is for | 41 | to a receiver's pubkey but there is no `p` tag pointing to the receiver. There is no way to know who the rumor is for |
| @@ -55,7 +55,7 @@ without the receiver's or the sender's private key. The only public information | |||
| 55 | 55 | ||
| 56 | Tags MUST always be empty in a `kind:13`. The inner event MUST always be unsigned. | 56 | Tags MUST always be empty in a `kind:13`. The inner event MUST always be unsigned. |
| 57 | 57 | ||
| 58 | ## 3. Gift Wrap Event Kind | 58 | ### 3. Gift Wrap Event Kind |
| 59 | 59 | ||
| 60 | A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information | 60 | A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information |
| 61 | needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work. | 61 | needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work. |
| @@ -72,12 +72,12 @@ needed to route the event to its intended recipient, including the recipient's ` | |||
| 72 | } | 72 | } |
| 73 | ``` | 73 | ``` |
| 74 | 74 | ||
| 75 | # Encrypting Payloads | 75 | ## Encrypting Payloads |
| 76 | 76 | ||
| 77 | Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content` | 77 | Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content` |
| 78 | of the wrapper event (either a `seal` or a `gift wrap`). | 78 | of the wrapper event (either a `seal` or a `gift wrap`). |
| 79 | 79 | ||
| 80 | # Other Considerations | 80 | ## Other Considerations |
| 81 | 81 | ||
| 82 | If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single | 82 | If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single |
| 83 | `rumor` may be wrapped and addressed for each recipient individually. | 83 | `rumor` may be wrapped and addressed for each recipient individually. |
| @@ -97,7 +97,7 @@ To protect recipient metadata, relays SHOULD only serve `kind 1059` events inten | |||
| 97 | When possible, clients should only send wrapped events to `read` relays for the recipient that implement | 97 | When possible, clients should only send wrapped events to `read` relays for the recipient that implement |
| 98 | AUTH, and refuse to serve wrapped events to non-recipients. | 98 | AUTH, and refuse to serve wrapped events to non-recipients. |
| 99 | 99 | ||
| 100 | # An Example | 100 | ## An Example |
| 101 | 101 | ||
| 102 | Let's send a wrapped `kind 1` message between two parties asking "Are you going to the party tonight?" | 102 | Let's send a wrapped `kind 1` message between two parties asking "Are you going to the party tonight?" |
| 103 | 103 | ||
| @@ -108,7 +108,7 @@ Let's send a wrapped `kind 1` message between two parties asking "Are you going | |||
| 108 | Note that this messaging protocol should not be used in practice, this is just an example. Refer to other | 108 | Note that this messaging protocol should not be used in practice, this is just an example. Refer to other |
| 109 | NIPs for concrete messaging protocols that depend on gift wraps. | 109 | NIPs for concrete messaging protocols that depend on gift wraps. |
| 110 | 110 | ||
| 111 | ## 1. Create an event | 111 | ### 1. Create an event |
| 112 | 112 | ||
| 113 | Create a `kind 1` event with the message, the receivers, and any other tags you want, signed by the author. | 113 | Create a `kind 1` event with the message, the receivers, and any other tags you want, signed by the author. |
| 114 | Do not sign the event. | 114 | Do not sign the event. |
| @@ -124,7 +124,7 @@ Do not sign the event. | |||
| 124 | } | 124 | } |
| 125 | ``` | 125 | ``` |
| 126 | 126 | ||
| 127 | ## 2. Seal the rumor | 127 | ### 2. Seal the rumor |
| 128 | 128 | ||
| 129 | Encrypt the JSON-encoded `rumor` with a conversation key derived using the author's private key and | 129 | Encrypt the JSON-encoded `rumor` with a conversation key derived using the author's private key and |
| 130 | the recipient's public key. Place the result in the `content` field of a `kind 13` `seal` event. Sign | 130 | the recipient's public key. Place the result in the `content` field of a `kind 13` `seal` event. Sign |
| @@ -142,7 +142,7 @@ it with the author's key. | |||
| 142 | } | 142 | } |
| 143 | ``` | 143 | ``` |
| 144 | 144 | ||
| 145 | ## 3. Wrap the seal | 145 | ### 3. Wrap the seal |
| 146 | 146 | ||
| 147 | Encrypt the JSON-encoded `kind 13` event with your ephemeral, single-use random key. Place the result | 147 | Encrypt the JSON-encoded `kind 13` event with your ephemeral, single-use random key. Place the result |
| 148 | in the `content` field of a `kind 1059`. Add a single `p` tag containing the recipient's public key. | 148 | in the `content` field of a `kind 1059`. Add a single `p` tag containing the recipient's public key. |
| @@ -160,13 +160,13 @@ Sign the `gift wrap` using the random key generated in the previous step. | |||
| 160 | } | 160 | } |
| 161 | ``` | 161 | ``` |
| 162 | 162 | ||
| 163 | ## 4. Broadcast Selectively | 163 | ### 4. Broadcast Selectively |
| 164 | 164 | ||
| 165 | Broadcast the `kind 1059` event to the recipient's relays only. Delete all the other events. | 165 | Broadcast the `kind 1059` event to the recipient's relays only. Delete all the other events. |
| 166 | 166 | ||
| 167 | # Code Samples | 167 | ## Code Samples |
| 168 | 168 | ||
| 169 | ## JavaScript | 169 | ### JavaScript |
| 170 | 170 | ||
| 171 | ```javascript | 171 | ```javascript |
| 172 | import {bytesToHex} from "@noble/hashes/utils" | 172 | import {bytesToHex} from "@noble/hashes/utils" |