nip01: relay-to-client message definitions.

why weren't these things here already?

nips/01.md

@@ -8,7 +8,7 @@ Basic protocol flow description
 
 This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.
 
-### Events and signatures
+## Events and signatures
 
 Each user has a keypair. Signatures, public key and encodings are done according to the [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340).
 
@@ -43,11 +43,13 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is
 ]
 ```
 
-### Communication between clients and relays
+## Communication between clients and relays
 
 Relays expose a websocket endpoint to which clients can connect.
 
-Clients can send either 3 types of messages, which must be JSON arrays, according to the following patterns:
+### 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:
 
   * `["EVENT", <event JSON as defined above>`], used to publish events.
   * `["REQ", <id>, <filter JSON>...`], used to request events and subscribe to new updates.
@@ -69,13 +71,24 @@ Clients can send either 3 types of messages, which must be JSON arrays, accordin
 }
 ```
 
-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 withe 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 `<id>` or a new `REQ` is sent using the same id, in which case it should overwrite the previous subscription.
 
 All conditions of a filter that are specified must be valid for an event for it to pass the filter, i.e., multiple conditions are interpreted as `&&` conditions.
 
 A `REQ` message may contain multiple filters. In this case events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
 
-### Basic Event Kinds
+### From relay to client: sending events and notices
+
+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.
+  * `["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.
+
+`EVENT` messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the `REQ` message above).
+
+## Basic Event Kinds
 
   - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <string>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
   - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say).
@@ -83,7 +96,7 @@ A `REQ` message may contain multiple filters. In this case events that match any
 
 A relay may choose to treat different message kinds differently, but it should default to returning all event kinds, even when it doesn't know what they mean.
 
-### Other Notes:
+## Other Notes:
 
 - Clients should not open more than one websocket to each relay. It also is advised that clients do not open more than 3 subscriptions to the same relay. 3 is enough for most use cases and relays should impose limits to prevent over usage by clients.
 - The `tags` array can store any kind of tag the message may be related to. This NIP defines `"p"` — meaning "profile", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow.