NIP-17 Typos and grammar improvements (#1840)

Author: vitorpamplona

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", "<file-mime-type>"],
     ["encryption-algorithm", "<encryption-algorithm>"],
     ["decryption-key", "<decryption-key>"],
-    ["decryptiion-nonce", "<decryption-nonce>"],
+    ["decryption-nonce", "<decryption-nonce>"],
     ["x", "<the SHA-256 hexencoded string of the file>"],
     // rest of tags...
   ],
@@ -74,24 +74,24 @@ Kind 15 is used for sending encrypted file event messages:
 - `content`: The URL of the file (`<file-url>`).
 - `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 `<width>x<height>`
-- `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 `<width>x<height>`
+- `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.
 
 An optional `subject` tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new `subject` to an existing `pubkey` + `p`-tags room. There is no need to send `subject` in every message. The newest `subject` in the thread is the subject of the conversation.
 
 ## 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