upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorfiatjaf_ <fiatjaf@gmail.com>2025-07-07 10:50:54 -0300
committerGitHub <noreply@github.com>2025-07-07 10:50:54 -0300
commit477e3dfd4d672a830d157f32c41795b7a143b9d7 (patch)
tree2905435732e0363a96f95c41238a0001bdb23165
parent9afca6c4dcd3a95f1e05b8452eb3000e50de5e7b (diff)
add "mute" OK=false status for no-op ephemeral events (#1965)
-rw-r--r--01.md5
1 files changed, 3 insertions, 2 deletions
diff --git a/01.md b/01.md
index 904f068..1f56427 100644
--- a/01.md
+++ b/01.md
@@ -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
88Kinds 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. 88Kinds 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
90This NIP defines one basic kind: 90This 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.