text changes

nips/01.md

@@ -52,17 +52,17 @@ Relays expose a websocket endpoint to which clients can connect.
 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>, <filter JSON>...`], used to request events and subscribe to new updates.
+  * `["REQ", <subscription_id>, <filters JSON>...`], used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
-`<id>` is a random string that should be used to represent a subscription. The same
+`<subscription_id>` is a random string that should be used to represent a subscription.
 
 `<filters>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
 
 ```
 {
   "ids": <a list of event ids>,
-  "kinds": <a list of a kind numbers>,
+  "kinds": <a list of kind numbers>,
   "#e": <a list of event ids that are referenced in an "e" tag>,
   "#p": <a list of pubkeys that are referenced in a "p" tag>,
   "since": <a timestamp, events must be newer than this to pass>,
@@ -71,7 +71,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
 }
 ```
 
-Upon receiving a `REQ` message, the relay MUST query its internal database and return events that match the filter, then store that filter and send again all future events it receives to that same websocket until the websocket is closed, the `CLOSE` event is received with the same `<id>` or a new `REQ` is sent using the same id, in which case it should overwrite the previous subscription.
+Upon receiving a `REQ` message, the relay MUST query its internal database and return events that match the filter, then store that filter and send again all future events it receives to that same websocket until the websocket is closed. The `CLOSE` event is received with the same `<subscription_id>` or a new `REQ` is sent using the same `<subscription_id>`, in which case it should overwrite the previous subscription.
 
 Filter attributes containing lists (such as `ids`, `kinds`, or `#e`) are JSON arrays with one or more values.  At least one of the array's values must match the relevant field in an event for the condition itself to be considered a match.  For scalar event attributes such as `kind`, the attribute from the event must be contained in the filter list.  For tag attributes such as `#e`, where an event may have multiple values, the event and filter condition values must have at least one item in common.
 
@@ -83,7 +83,7 @@ A `REQ` message may contain multiple filters. In this case events that match any
 
 Relays can send 2 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.
+  * `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients.
   * `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients.
 
 This NIP defines no rules for how `NOTICE` messages should be sent or treated.