diff options
| -rw-r--r-- | 01.md | 3 |
1 files changed, 1 insertions, 2 deletions
| @@ -99,8 +99,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. | |||
| 99 | ## Basic Event Kinds | 99 | ## Basic Event Kinds |
| 100 | 100 | ||
| 101 | - `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. | 101 | - `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. |
| 102 | - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say).\ | 102 | - `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. |
| 103 | Do not use Markdown! Clients should not have to guess how to interpret content like `[Example](https://example.com)`. Use different event kinds for parsable content. | ||
| 104 | - `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. | 103 | - `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. |
| 105 | 104 | ||
| 106 | 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. | 105 | 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. |