diff options
| -rw-r--r-- | 01.md | 5 | ||||
| -rw-r--r-- | 16.md | 5 | ||||
| -rw-r--r-- | 22.md | 3 |
3 files changed, 9 insertions, 4 deletions
| @@ -98,10 +98,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. | |||
| 98 | ## Basic Event Kinds | 98 | ## Basic Event Kinds |
| 99 | 99 | ||
| 100 | - `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. | 100 | - `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 | * Where `<username>` is a string that matches the pattern: `\w[\w\-]+\w` (java regular expression). Or, in other words, a sequence of the following | 101 | - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say). Non-plaintext notes should instead use kind 1000-10000 as described in [NIP-16](16.md). |
| 102 | characters: `[a-zA-Z_0-9][a-zA-Z_\-0-9]+[a-zA-Z_0-9]`. <br> | ||
| 103 | Thus `George-Washington-1776` is a valid `<username>`, but `George Washington` is not. Clients may reject metadata that does not comply. | ||
| 104 | - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say). | ||
| 105 | - `2`: `recommend_server`: the `content` is set to the URL (e.g., `https://somerelay.com`) of a relay the event creator wants to recommend to its followers. | 102 | - `2`: `recommend_server`: the `content` is set to the URL (e.g., `https://somerelay.com`) of a relay the event creator wants to recommend to its followers. |
| 106 | 103 | ||
| 107 | 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. | 104 | 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. |
| @@ -8,6 +8,11 @@ Event Treatment | |||
| 8 | 8 | ||
| 9 | Relays may decide to allow replaceable and/or ephemeral events. | 9 | Relays may decide to allow replaceable and/or ephemeral events. |
| 10 | 10 | ||
| 11 | Regular Events | ||
| 12 | ------------------ | ||
| 13 | A *regular event* is defined as an event with a kind `1000 <= n < 10000`. | ||
| 14 | Upon a regular event being received, the relay SHOULD send it to all clients with a matching filter, and SHOULD store it. New events of the same kind do not affect previous events in any way. | ||
| 15 | |||
| 11 | Replaceable Events | 16 | Replaceable Events |
| 12 | ------------------ | 17 | ------------------ |
| 13 | A *replaceable event* is defined as an event with a kind `10000 <= n < 20000`. | 18 | A *replaceable event* is defined as an event with a kind `10000 <= n < 20000`. |
| @@ -26,6 +26,9 @@ The event `created_at` field is just a unix timestamp and can be set to a time i | |||
| 26 | 26 | ||
| 27 | A wide adoption of this nip could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future. | 27 | A wide adoption of this nip could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future. |
| 28 | 28 | ||
| 29 | Keep in mind that there is a use case where a user migrates their old posts onto a new relay. If a relay rejects events that were not recently created, it cannot serve this use case. | ||
| 30 | |||
| 31 | |||
| 29 | Python Example | 32 | Python Example |
| 30 | -------------- | 33 | -------------- |
| 31 | 34 | ||