diff options
Diffstat (limited to '01.md')
| -rw-r--r-- | 01.md | 20 |
1 files changed, 16 insertions, 4 deletions
| @@ -29,7 +29,7 @@ The only object type that exists is the `event`, which has the following format | |||
| 29 | } | 29 | } |
| 30 | ``` | 30 | ``` |
| 31 | 31 | ||
| 32 | To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no white space or line breaks between the fields) of the following structure: | 32 | To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (which is described below) of the following structure: |
| 33 | 33 | ||
| 34 | ``` | 34 | ``` |
| 35 | [ | 35 | [ |
| @@ -42,6 +42,18 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is | |||
| 42 | ] | 42 | ] |
| 43 | ``` | 43 | ``` |
| 44 | 44 | ||
| 45 | To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing: | ||
| 46 | - No whitespace, line breaks or other unnecessary formatting should be included in the output JSON. | ||
| 47 | - No characters except the following should be escaped, and instead should be included verbatim: | ||
| 48 | - A line break, `0x0A`, as `\n` | ||
| 49 | - A double quote, `0x22`, as `\"` | ||
| 50 | - A backslash, `0x5C`, as `\\` | ||
| 51 | - A carriage return, `0x0D`, as `\r` | ||
| 52 | - A tab character, `0x09`, as `\t` | ||
| 53 | - A backspace, `0x08`, as `\b` | ||
| 54 | - A form feed, `0x0C`, as `\f` | ||
| 55 | - UTF-8 should be used for encoding. | ||
| 56 | |||
| 45 | ### Tags | 57 | ### Tags |
| 46 | 58 | ||
| 47 | Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below: | 59 | Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below: |
| @@ -101,12 +113,12 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD | |||
| 101 | Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns: | 113 | Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns: |
| 102 | 114 | ||
| 103 | * `["EVENT", <event JSON as defined above>]`, used to publish events. | 115 | * `["EVENT", <event JSON as defined above>]`, used to publish events. |
| 104 | * `["REQ", <subscription_id>, <filters JSON>, ...]`, used to request events and subscribe to new updates. | 116 | * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates. |
| 105 | * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions. | 117 | * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions. |
| 106 | 118 | ||
| 107 | `<subscription_id>` is an arbitrary, non-empty string of max length 64 chars, that should be used to represent a subscription. Relays should manage `<subscription_id>`s independently for each WebSocket connection; even if `<subscription_id>`s are the same string, they should be treated as different subscriptions for different connections. | 119 | `<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guarantueed to be globally unique. |
| 108 | 120 | ||
| 109 | `<filters>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes: | 121 | `<filtersX>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes: |
| 110 | 122 | ||
| 111 | ```json | 123 | ```json |
| 112 | { | 124 | { |