diff options
Diffstat (limited to '01.md')
| -rw-r--r-- | 01.md | 20 |
1 files changed, 10 insertions, 10 deletions
| @@ -43,16 +43,16 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is | |||
| 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: | 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. | 46 | - UTF-8 should be used for encoding. |
| 47 | - Whitespace, line breaks or other unnecessary formatting should not be included in the output JSON. | ||
| 48 | - The following characters in the content field must be escaped as shown, and all other characters must be included verbatim: | ||
| 49 | - A line break (`0x0A`), use `\n` | ||
| 50 | - A double quote (`0x22`), use `\"` | ||
| 51 | - A backslash (`0x5C`), use `\\` | ||
| 52 | - A carriage return (`0x0D`), use `\r` | ||
| 53 | - A tab character (`0x09`), use `\t` | ||
| 54 | - A backspace, (`0x08`), use `\b` | ||
| 55 | - A form feed, (`0x0C`), use `\f` | ||
| 56 | 56 | ||
| 57 | ### Tags | 57 | ### Tags |
| 58 | 58 | ||
| @@ -87,7 +87,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key | |||
| 87 | 87 | ||
| 88 | Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds: | 88 | Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds: |
| 89 | 89 | ||
| 90 | - `0`: **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. | 90 | - `0`: **metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey. |
| 91 | - `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. | 91 | - `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. |
| 92 | 92 | ||
| 93 | And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation: | 93 | And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation: |