header formats

01.md

@@ -8,7 +8,7 @@ Nostr Protocol
 
 This NIP defines the complete protocol that MUST be implemented by everybody. New NIPs may add new optional (or mandatory) fields, messages and features to the structures and flows described here.
 
-## Events
+# Events
 
 Event is only object type available. It is a hashed and signed payload with the following format:
 
@@ -57,7 +57,7 @@ To verify an event:
 1. Recalculate the hash and check against the `.id`
 2. Verify if the signature is valid for the `.id`. 
 
-### Kinds
+## Kinds
 
 The `.kind` property specifies the meaning of an event and its tags. 
 
@@ -77,7 +77,7 @@ This NIP defines two kinds:
 - `kind:0`: **User 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 older events once it gets a new one for the same pubkey.
 - `kind:1`: **Text Note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
 
-### Tags
+## Tags
 
 Each tag is an array of strings of arbitrary size. Their meaning is determined by the event `.kind` and defined in NIPs in this repository. Tags with the same name might have entirely different meanings in diferent kinds. 
 
@@ -107,17 +107,17 @@ This NIP defines the format of 3 standard tags that can be used across all event
 
 All single-letter (only english alphabet letters: a-z, A-Z) key tags indexed by relays for faster queries. 
 
-## Relay Protocol
+# Relay Protocol
 
 Nostr has two main components: Clients & Relays. Users run a client to fetch/subscribe to events from one or more Relays via websockets. Relays are not expected to communicate with one another. It's  the Client's responsibility to discover which relay has the event set their user wants to see. Both sides SHOULD verify the hash and the signature of each event upon receipt. 
 
 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. All messages are defined as JSON arrays. 
 
-### Subscriptions
+## Subscriptions
 
 Clients send a **subscription** message with one or more filters. The Relay MUST query its database, return all events that match the filter and keep applying the filter to all connections, returning new events as they arrive. Subscriptions stay indefinatelly open until either side closes the subscription or the connection. 
 
-#### Subscription Requests
+### Subscription Requests
 
 To open, update and close subscriptions, Clients MUST use the following formats: 
   * `["REQ", <subscription_id>, <filter1>, <filter2>, ...]`, used to request events and subscribe to new updates.
@@ -151,7 +151,7 @@ The `since` and `until` properties are used to specify the time range of events
 
 The `limit` property operates over the stored events and is ignored afterwards. 
 
-#### Receiving Events
+### Receiving Events
 
 Relays send 3 types of messages during a subscription:  
 
@@ -163,7 +163,7 @@ All messages MUST be sent with the subscription_id initiated by the client (usin
 
 `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`. The message MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message.
 
-### Broadcasting an Event
+## Broadcasting an Event
 
 To send an event to the Relay, Clients send a broadcast message in the format: 
 
@@ -177,13 +177,13 @@ Relays reply with an ACK message in the format of:
 
 If present, the message MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. 
 
-### Notices
+## Notices
 
 Notices are warnings that might help explain or debug the behaviour of a given relay. 
 
   * `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients.
 
-### Error Codes
+## Error Codes
 
 The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits.