From ea587f58d2bc7dcd80493e2ca071393a66ac78c1 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Thu, 13 Mar 2025 09:12:14 -0400 Subject: [PATCH] NIP-17 Typos and grammar improvements --- 17.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/17.md b/17.md index 487d01ed..4383308c 100644 --- a/17.md +++ b/17.md @@ -57,7 +57,7 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela ["file-type", ""], ["encryption-algorithm", ""], ["decryption-key", ""], - ["decryptiion-nonce", ""], + ["decryption-nonce", ""], ["x", ""], // rest of tags... ], @@ -74,16 +74,16 @@ Kind 15 is used for sending encrypted file event messages: - `content`: The URL of the file (``). - `x` containing the SHA-256 hexencoded string of the file. - `size` (optional) size of file in bytes -- `dim` (optional) size of file in pixels in the form `x` -- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client -- `thumb` (optional) url of thumbnail with same aspect ratio +- `dim` (optional) size of the file in pixels in the form `x` +- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file +- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce) - `fallback` (optional) zero or more fallback file sources in case `url` fails Just like kind 14, kind `15`s MUST never be signed. ## Chat Rooms -The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history. +The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history. Clients SHOULD render messages of the same room in a continuous thread. @@ -91,7 +91,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An ## Encrypting -Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually. +Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually. ```jsonc { @@ -173,7 +173,7 @@ The main limitation of this approach is having to send a separate encrypted even Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast. -When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set. +When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set. ## Examples