diff --git a/01.md b/01.md
index 60d9785..5c52e35 100644
--- a/01.md
+++ b/01.md
@@ -109,7 +109,7 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD
 
 ### From client to relay: sending events and creating subscriptions
 
-Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
+Clients can send 3 types of messages (as JSON arrays) according to the following patterns:
 
   * `["EVENT", <event JSON as defined above>]`, used to publish events.
   * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
@@ -147,9 +147,9 @@ 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 5 types of messages, which must also be JSON arrays, according to the following patterns:
+Relays can send 5 types of messages (as JSON arrays) according to the following patterns:
 
-  * `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients.
+  * `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients. The difference in structure between this and a client-initiated "EVENT" is the <subscription_id>.
   * `["OK", <event_id>, <true|false>, <message>]`, used to indicate acceptance or denial of an `EVENT` message.
   * `["EOSE", <subscription_id>]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time.
   * `["CLOSED", <subscription_id>, <message>]`, used to indicate that a subscription was ended on the server side.
@@ -157,8 +157,8 @@ Relays can send 5 types of messages, which must also be JSON arrays, according t
 
 This NIP defines no rules for how `NOTICE` messages should be sent or treated.
 
-- `EVENT` messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the `REQ` message above).
-- `OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is `true`, otherwise it MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. Some examples:
+`EVENT` messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the `REQ` message above).
+`OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is `true`, otherwise it MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. Some examples:
   * `["OK", "b1a649ebe8...", true, ""]`
   * `["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]`
   * `["OK", "b1a649ebe8...", true, "duplicate: already have this event"]`
@@ -168,9 +168,9 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
   * `["OK", "b1a649ebe8...", false, "invalid: event creation date is too far off from the current time"]`
   * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]`
   * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]`
-- `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
+`CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
   * `["CLOSED", "sub1", "duplicate: sub1 already opened"]`
   * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
   * `["CLOSED", "sub1", "error: could not connect to the database"]`
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]`
-- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits.
+The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits.