1 files changed, 13 insertions, 11 deletions

diff --git a/01.md b/01.md
index d040666..e36f4f5 100644
--- a/01.md
+++ b/01.md
@@ -4,7 +4,7 @@ NIP-01
 Basic protocol flow description
 -------------------------------
 
-`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55`
+`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55` `author:semisol`
 
 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.
 
@@ -16,17 +16,17 @@ The only object type that exists is the `event`, which has the following format
 
 ```json
 {
-  "id": <32-bytes sha256 of the the serialized event data>
-  "pubkey": <32-bytes hex-encoded public key of the event creator>,
+  "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
+  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": <integer>,
   "tags": [
     ["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
-    ["p", <32-bytes hex of the key>, <recommended relay URL>],
+    ["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
     ... // other kinds of tags may be included later
   ],
   "content": <arbitrary string>,
-  "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
 }
 ```
 
@@ -55,7 +55,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   * `["REQ", <subscription_id>, <filters JSON>...]`, used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
-`<subscription_id>` is a random string that should be used to represent a subscription.
+`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars, 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:
 
@@ -66,8 +66,8 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "kinds": <a list of a 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>,
-  "until": <a timestamp, events must be older than this to pass>,
+  "since": <an integer unix timestamp, events must be newer than this to pass>,
+  "until": <an integer unix timestamp, events must be older than this to pass>,
   "limit": <maximum number of events to be returned in the initial query>
 }
 ```
@@ -86,9 +86,10 @@ The `limit` property of a filter is only valid for the initial query and can be
 
 ### 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:
+Relays can send 3 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.
+  * `["EOSE", <subscription_id>]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time.
   * `["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.
@@ -98,7 +99,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
 ## Basic Event Kinds
 
   - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, 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). Non-plaintext notes should instead use kind 1000-10000 as described in [NIP-16](16.md).
+  - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Do not use Markdown! Clients should not have to guess how to interpret content like `[]()`. Use different event kinds for parsable content.
   - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers.
 
 A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.
@@ -106,5 +107,6 @@ A relay may choose to treat different message kinds differently, and it may or m
 ## Other Notes:
 
 - Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that.
-- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", 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.
+- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", 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. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags.
 - The `<recommended relay URL>` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.
+- Clients should use the created_at field to judge the age of a metadata event and completely replace older metadata events with newer metadata events regardless of the order in which they arrive.  Clients should not merge any filled fields within older metadata events into empty fields of newer metadata events.