nip01: fix json formatting.

nips/01.md

@@ -13,34 +13,35 @@ This NIP defines the basic protocol that should be implemented by everybody. New
 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).
 
 The single object type that exists is the `event`, which has the following format on the wire:
-    ```
+
-    {
+```
-      id: <32-bytes sha256 of the the serialized event data>
+{
-      pubkey: <32-bytes hex-encoded public key of the event creator>,
+  id: <32-bytes sha256 of the the serialized event data>
-      created_at: <unix timestamp in seconds>,
+  pubkey: <32-bytes hex-encoded public key of the event creator>,
-      kind: <integer>,
+  created_at: <unix timestamp in seconds>,
-      tags: [
+  kind: <integer>,
-        ["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
+  tags: [
-        ["p", <32-bytes hex of the key>, <recommended relay URL>],
+    ["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
-        ... // other kinds of tags may be included later
+    ["p", <32-bytes hex of the key>, <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>,
+  content: <arbitrary string>,
-    }
+  sig: <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>,
-    ```
+}
+```
 
 To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no indentation or extra spaces) of the following structure:
 
-    ```
+```
-    [
+[
-      0,
+  0,
-      <pubkey, as a hex string>,
+  <pubkey, as a hex string>,
-      <created_at, as a number>,
+  <created_at, as a number>,
-      <kind, as a number>,
+  <kind, as a number>,
-      <tags, as an array of arrays>,
+  <tags, as an array of arrays>,
-      <content>, as a string
+  <content>, as a string
-    ]
+]
-    ```
+```
 
 ### Communication between clients and relays
 
@@ -56,17 +57,17 @@ Clients can send either 3 types of messages, which must be JSON arrays, accordin
 
 `<filters>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
 
-    ```
+```
-    {
+{
-      "id": <the id of an event>,
+  "id": <the id of an event>,
-      "author": <the pubkey of an event that identifies its author>,
+  "author": <the pubkey of an event that identifies its author>,
-      "kind": <a kind number>
+  "kind": <a kind number>
-      "#e": <an event id that is referenced in an "e" tag>,
+  "#e": <an event id that is referenced in an "e" tag>,
-      "#p": <a pubkey that is referenced in a "p" tag>,
+  "#p": <a pubkey that is referenced in a "p" tag>,
-      "since": <a timestamp, events must be newer than this to pass>,
+  "since": <a timestamp, events must be newer than this to pass>,
-      "authors": <a list of pubkeys, the pubkey of an event must be one of these>
+  "authors": <a list of pubkeys, the pubkey of an event must be one of these>
-    }
+}
-    ```
+```
 
 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.