1 files changed, 25 insertions, 14 deletions

diff --git a/01.md b/01.md
index 99c991a..8be85bc 100644
--- a/01.md
+++ b/01.md
@@ -14,7 +14,7 @@ Each user has a keypair. Signatures, public key, and encodings are done accordin
 
 The only object type that exists is the `event`, which has the following format on the wire:
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -22,14 +22,14 @@ The only object type that exists is the `event`, which has the following format
   "kind": <integer between 0 and 65535>,
   "tags": [
     [<arbitrary string>...],
-    ...
+    // ...
   ],
   "content": <arbitrary string>,
   "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
 }
 ```
 
-To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no white space or line breaks between the fields) of the following structure:
+To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (which is described below) of the following structure:
 
 ```
 [
@@ -42,21 +42,32 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is
 ]
 ```
 
+To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing:
+- No whitespace, line breaks or other unnecessary formatting should be included in the output JSON.
+- No characters except the following should be escaped, and instead should be included verbatim:
+  - A line break, `0x0A`, as `\n`
+  - A double quote, `0x22`, as `\"`
+  - A backslash, `0x5C`, as `\\`
+  - A carriage return, `0x0D`, as `\r`
+  - A tab character, `0x09`, as `\t`
+  - A backspace, `0x08`, as `\b`
+  - A form feed, `0x0C`, as `\f`
+- UTF-8 should be used for encoding.
+
 ### Tags
 
-Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
+Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below:
 
-```json
+```jsonc
 {
-  ...,
   "tags": [
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
     ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
     ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
     ["alt", "reply"],
-    ...
+    // ...
   ],
-  ...
+  // ...
 }
 ```
 
@@ -70,7 +81,7 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
     - for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
     - for a non-parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
 
-As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"}` filter.
+As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
 
 ### Kinds
 
@@ -101,19 +112,19 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD
 Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
 
   * `["EVENT", <event JSON as defined above>]`, used to publish events.
-  * `["REQ", <subscription_id>, <filters JSON>...]`, used to request events and subscribe to new updates.
+  * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
-`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars, that should be used to represent a subscription. Relays should manage `<subscription_id>`s independently for each WebSocket connection; even if `<subscription_id>`s are the same string, they should be treated as different subscriptions for different connections.
+`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guaranteed to be globally unique.
 
-`<filters>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
+`<filtersX>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
 
 ```json
 {
   "ids": <a list of event ids>,
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
   "kinds": <a list of a kind numbers>,
-  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of event pubkeys etc>,
+  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
   "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
   "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
   "limit": <maximum number of events relays SHOULD return in the initial query>
@@ -136,7 +147,7 @@ The `limit` property of a filter is only valid for the initial query and MUST be
 
 ### From relay to client: sending events and notices
 
-Relays can send 4 types of messages, which must also be JSON arrays, according to the following patterns:
+Relays can send 5 types of messages, which must also be JSON arrays, according to the following patterns:
 
   * `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients.
   * `["OK", <event_id>, <true|false>, <message>]`, used to indicate acceptance or denial of an `EVENT` message.