diff options
Diffstat (limited to '01.md')
| -rw-r--r-- | 01.md | 5 |
1 files changed, 3 insertions, 2 deletions
| @@ -85,7 +85,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key | |||
| 85 | 85 | ||
| 86 | ### Kinds | 86 | ### Kinds |
| 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. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications. | 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. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications. |
| 89 | 89 | ||
| 90 | This NIP defines one basic kind: | 90 | This NIP defines one basic kind: |
| 91 | 91 | ||
| @@ -170,8 +170,9 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. | |||
| 170 | * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]` | 170 | * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]` |
| 171 | * `["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]` | 171 | * `["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]` |
| 172 | * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]` | 172 | * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]` |
| 173 | * `["OK", "b1a649ebe8...", false, "mute: no one was listening to your ephemeral event and it wasn't handled in any way, it was ignored"]` | ||
| 173 | - `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples: | 174 | - `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples: |
| 174 | * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]` | 175 | * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]` |
| 175 | * `["CLOSED", "sub1", "error: could not connect to the database"]` | 176 | * `["CLOSED", "sub1", "error: could not connect to the database"]` |
| 176 | * `["CLOSED", "sub1", "error: shutting down idle subscription"]` | 177 | * `["CLOSED", "sub1", "error: shutting down idle subscription"]` |
| 177 | - The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, and `error` for when none of that fits. | 178 | - The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, `mute` and `error` for when none of that fits. |