Consistency and small refinements for NIP-01 (#731)

1 files changed, 11 insertions, 11 deletions

diff --git a/01.md b/01.md
index 6369743..d6ccfbe 100644
--- a/01.md
+++ b/01.md
@@ -25,7 +25,7 @@ The only object type that exists is the `event`, which has the following format
     ...
   ],
   "content": <arbitrary string>,
-  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+  "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>
 }
 ```
 
@@ -34,7 +34,7 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is
 ```json
 [
   0,
-  <pubkey, as a (lowercase) hex string>,
+  <pubkey, as a lowercase hex string>,
   <created_at, as a number>,
   <kind, as a number>,
   <tags, as an array of arrays of non-null strings>,
@@ -64,11 +64,11 @@ The first element of the tag array is referred to as the tag _name_ or _key_ and
 
 This NIP defines 3 standard tags that can be used accross all event kinds with the same meaning. They are as follows:
 
-- The `e` tag, used to refer to an event: `["e", <32-bytes hex of the id of another event>, <recommended relay URL, optional>]`
-- The `p` tag, used to refer to another user: `["p", <32-bytes hex of a pubkey>, <recommended relay URL, optional>]`
-- The `a` tag, used to refer to a parameterized replaceable event: `["a", <kind integer>:<32-bytes hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
+- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]`
+- The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
+- The `a` tag, used to refer to a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
 
-As a convention, all single-letter 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
 
@@ -80,7 +80,7 @@ Kinds specify how clients should interpret the meaning of each event and the oth
 And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
 
 - for kind `n` such that `1000 <= n < 10000`, events are **regular**, which means they're all expected to be stored by relays.
-- for kind `n` such that `10000 <= n < 20000 || k == 0 || k == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event is expected to be stored by relays, older versions are expected to be discarded.
+- for kind `n` such that `10000 <= n < 20000 || k == 0 || k == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event is expected to (SHOULD) be stored by relays, older versions are expected to be discarded.
 - for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
 - for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag, only the latest event is expected to be stored by relays, older versions are expected to be discarded.
 
@@ -90,7 +90,7 @@ These are just conventions and relay implementations may differ.
 
 ## Communication between clients and relays
 
-Relays expose a websocket endpoint to which clients can connect. Clients should open a single websocket connection to each relay and use it for all their subscriptions.
+Relays expose a websocket endpoint to which clients can connect. Clients SHOULD open a single websocket connection to each relay and use it for all their subscriptions. Relays MAY limit number of connections from specific IP/client/etc.
 
 ### Meaning of WebSocket status codes
 
@@ -113,14 +113,14 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "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 list of event ids that are referenced in the tag specified by the single letter>,
+  "#<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>,
   "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 to be returned in the initial query>
+  "limit": <maximum number of events relays SHOULD return in the initial query>
 }
 ```
 
-Upon receiving a `REQ` message, the relay SHOULD 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.
+Upon receiving a `REQ` message, the relay SHOULD 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 relay MUST overwrite the previous subscription.
 
 Filter attributes containing lists (`ids`, `authors`, `kinds` and tag filters like `#e`) are JSON arrays with one or more values. At least one of the arrays' values must match the relevant field in an event for the condition to be considered a match. For scalar event attributes such as `authors` and `kind`, the attribute from the event must be contained in the filter list. In the case of tag attributes such as `#e`, for which an event may have multiple values, the event and filter condition values must have at least one item in common.