Merge 2c041a8b5c into a551c5b693

Small grammatical suggestion, and fixed formatting of bullet points.

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.

89.md

@@ -116,7 +116,7 @@ User B might see in their timeline an event referring to a `kind:31337` event (e
 User B's client, not knowing how to handle a `kind:31337` might display the event using its `alt` tag (as described in NIP-31). When the user clicks on the event, the application queries for a handler for this `kind`:
 
 ```json
-["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']
+["REQ", <id>, { "kinds": [31989], "#d": ["31337"], "authors": [<user>, <users-contact-list>] }]
 ```
 
 User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information.
@@ -127,5 +127,5 @@ User B's client sees the application's `kind:31990` which includes the informati
 Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
 
 ```json
-["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']
+["REQ", <id>, { "kinds": [31990], "#k": [<desired-event-kind>], "authors": [...] }]
 ```