upleb.uk

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

summaryrefslogtreecommitdiff
path: root/66.md
diff options
context:
space:
mode:
Diffstat (limited to '66.md')
-rw-r--r--66.md231
1 files changed, 40 insertions, 191 deletions
diff --git a/66.md b/66.md
index 7ab3786..9f06ff5 100644
--- a/66.md
+++ b/66.md
@@ -4,139 +4,46 @@ NIP-66
4Relay Discovery and Liveness Monitoring 4Relay Discovery and Liveness Monitoring
5------------------- 5-------------------
6 6
7`draft` `optional` 7`draft` `optional` `relay`
8 8
9You want to find relays. You may want to discover relays based on criteria that's up to date. You may even want to ensure that you have a complete dataset. You probably want to filter relays based on their reported liveness. 9This NIP defines events for relay discovery and the announcement of relay monitors.
10 10
11In its purest form: 11## Relay Discovery Events
12 12
13```json 13`30166` relay discovery events document relay characteristics inferred either from a relay's [NIP 11](https://github.com/nostr-protocol/nips/blob/master/11.md) document, or via probing.
14{
15 "kind": 30166,
16 "created_at": 1722173222,
17 "content": "{}",
18 "tags": [
19 [ "d", "wss://somerelay.abc/" ]
20 ],
21 "pubkey": "<pubkey>",
22 "sig": "<signature>",
23 "id": "<eventid>"
24}
25```
26
27This event signals that the relay at `wss://somerelay.abc/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
28
29## Kinds
30`NIP-66` defines two (2) event kinds, `30166` and `10166`
31
32| kind | name | description |
33|-------|----------------------------|-----------------------------------------------------------------------------------------|
34| [30166](#k30166) | Relay Discovery | An addressable event that is published by a monitor when a relay is online |
35| [10166](#k10166) | Relay Monitor Announcement | An RE that stores data that signals the intent of a pubkey to monitor relays and publish `30166` events at a regular _frequency_ |
36
37## Ontology
38- `Relay Operator`: someone who operates a relay
39- `Monitor`: A pubkey that monitors relays and publishes `30166` events at the frequency specified in their `10166` event.
40- `Ad-hoc Monitor`: A pubkey that monitors relays and publishes `30166` events at an irregular frequency.
41- `Monitor Service`: A group or individual that monitors relays using one or more `Monitors`.
42- `Check`: a specific data point that is tested or aggregated by a monitor.
43
44## `30166`: "Relay Discovery" <a id="k30166"></a>
45
46### Summary
47`30166` is a `NIP-33` addressable event, referred to as a "Relay Discovery" event. These events are optimized with a small footprint for protocol-level relay Discovery.
48
49### Purpose
50Discovery of relays over nostr.
51
52### Schema
53
54#### Content
55`30166` content fields **SHOULD** include the stringified JSON of the relay's NIP-11 informational document. This data **MAY** be provided for informational purposes only.
56
57#### `created_at`
58The `created_at` field in a NIP-66 event should reflect the time when the relay liveness (and potentially other data points) was checked.
59
60#### `tags`
61
62##### Meta Tags (unindexed)
63- `rtt-open` The relay's open **round-trip time** in milliseconds.
64- `rtt-read` The relay's read **round-trip time** in milliseconds.
65- `rtt-write` The relay's write **round-trip time** in milliseconds.
66
67_Other `rtt` values **MAY** be present. This NIP should be updated if there is value found in more `rtt` values._
68
69##### Single Letter Tags (indexed)
70- `d` The relay URL/URI. The `#d` tag **must** be included in the `event.tags[]` array. Index position `1` **must** be the relay websocket URL/URI. If a URL it **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6). For relays not accessible via conventional means but rather by an npub/pubkey, an npub/pubkey **MAY** be used in place of a URL.
71 ```json
72 [ "d", "wss://somerelay.abc/"]
73 ```
74
75- `n`: Network
76 ```json
77 [ "n", "clearnet" ]
78 ```
79
80- `T`: Relay Type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`
81 ```json
82 ["T", "PrivateInbox" ]
83 ```
84
85- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
86 ```json
87 [ "N", "42" ]
88 ```
89
90- `R`: Requirements _NIP-11 "Informational Document" `nip11.limitations.payment_required`, `nip11.limitations.auth_required` and/or any other boolean value within `nip11.limitations[]` that is added in the future_
91 ```json
92 [ "R", "payment" ],
93 [ "R", "auth" ],
94 ```
95 Since the nostr protocol does not currently support filtering on whether an indexed tag **is** or **is not** set, to make "public" and "no auth" relays discoverable requires a `!` flag
96 14
97 ```json 15Information corresponding to field in a relay's NIP 11 document MAY contradict actual values if monitors find that a different policy is implemented than is advertised.
98 [ "R", "!payment" ], //no payment required, is public
99 [ "R", "!auth" ], //no authentication required
100 ```
101 16
102- `t`: "Topics" _From NIP-11 "Informational Document" `nip11.tags[]`_ 17`content` MAY include the stringified JSON of the relay's NIP-11 informational document.
103 ```json
104 [ "t", "nsfw" ]
105 ```
106 18
107- `k`: Accepted/Blocked Kinds [`NIP-22`] 19The only required tag is the `d` tag, which MUST be set to the relay's [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6) URL. For relays not accessible via URL, a hex-encoded pubkey MAY be used instead.
108 ```json
109 [ "k", "0" ],
110 [ "k", "3" ],
111 [ "k", "10002" ]
112 ```
113 20
114 or for blocked kinds 21Other tags include:
115 22
116 ```json 23- `rtt-open` - The relay's open round-trip time in milliseconds.
117 [ "k", "!0" ] 24- `rtt-read` - The relay's read round-trip time in milliseconds.
118 [ "k", "!3" ], 25- `rtt-write` - The relay's write round-trip time in milliseconds.
119 [ "k", "!10002" ] 26- `n` - The relay's network type. SHOULD be one of `clearnet`, `tor`, `i2p`, `loki`
120 ``` 27- `T` - The relay type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`, e.g. `PrivateInbox`
28- `N` - NIPs supported by the relay
29- `R` - Keys corresponding to requirements per [NIP 11](https://github.com/nostr-protocol/nips/blob/master/11.md)'s `limitations` array, including `auth`, `writes`, `pow`, and `payment`. False values should be specified using a `!` prefix, for example `!auth`.
30- `t` - A topic associated with this relay
31- `k` - Accepted and unaccepted kinds (false values prepended by `!`)
32- `g` - A [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash
121 33
122- `g`: `NIP-52` `g` tags (geohash) 34Tags with more than one value should be repeated, rather than putting all values in a single tag, for example `[["t", "cats"], ["t", "dogs"]]`, rather than `[["t", "cats", "dogs"]]`.
123 ```json
124 [ "g", "9r1652whz" ]
125 ```
126 35
127- `30166` **MAY** be extended with global tags defined by other NIPs that do no collide with locally defined indices, including but not limited to: `p`, `t`, `e`, `a`, `i` and `l/L`. 36Example:
128 37
129#### Robust Example of a `30166` Event
130_Relay was online, and you can filter on a number of different tags_
131```json 38```json
132{ 39{
133 "id": "<eventid>", 40 "id": "<eventid>",
134 "pubkey": "<monitor's pubkey>", 41 "pubkey": "<monitor's pubkey>",
135 "created_at": "<created_at [some recent date ...]>", 42 "created_at": "<created_at [some recent date ...]>",
136 "signature": "<signature>", 43 "signature": "<signature>",
137 "content": "{}", 44 "content": "<optional nip 11 document>",
138 "kind": 30166, 45 "kind": 30166,
139 "tags": [ 46 "tags": [
140 ["d","wss://some.relay/"], 47 ["d","wss://some.relay/"],
141 ["n", "clearnet"], 48 ["n", "clearnet"],
142 ["N", "40"], 49 ["N", "40"],
@@ -144,64 +51,28 @@ _Relay was online, and you can filter on a number of different tags_
144 ["R", "!payment"], 51 ["R", "!payment"],
145 ["R", "auth"], 52 ["R", "auth"],
146 ["g", "ww8p1r4t8"], 53 ["g", "ww8p1r4t8"],
147 ["p", "somehexkey..."],
148 ["l", "en", "ISO-639-1"], 54 ["l", "en", "ISO-639-1"],
149 ["t", "nsfw" ], 55 ["t", "nsfw" ],
150 ["rtt-open", 234 ] 56 ["rtt-open", "234" ]
151 ] 57 ]
152} 58}
153``` 59```
154 60
155## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a> 61## Relay Monitor Announcements
156
157### Summary
158`10166` is a replacable event herein referred to as "Relay Monitor Announcement" events. These events contain information about a publisher's intent to monitor and publish data as `30166` events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.
159
160### Purpose
161To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities. Absence of this event implies the monitor is ad-hoc and does not publish events at a predictable frequency, and relies on mechanisms to infer data integrity, such as web-of-trust.
162
163### Schema
164
165#### Standard Tags
166 62
167- `frequency` The frequency **in seconds** at which the monitor publishes events. A string-integer at index `1` represents the expected frequency the monitor will publish `30166` events. There should only be `1` frequency per monitor. 63Kind `10166` relay monitor announcements advertise the author's intent to publish `30166` events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.
168 64
169 ```json 65Tags include:
170 [ "frequency", "3600" ]
171 ```
172 66
173- `timeout` (optional) The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests. These values can assist relay operators in understanding data signaled by the monitor in _Relay Discovery Events_. 67- `frequency` - The frequency in seconds at which the monitor publishes events.
174 ```json 68- `timeout` (optional) - The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests.
175 [ "timeout", "2000", "open" ], 69- `c` - a lowercase string describing the checks conducted by a monitor. Examples include `open`, `read`, `write`, `auth`, `nip11`, `dns`, and `geo`.
176 [ "timeout", "2000", "read" ], 70- `g` - [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash tag
177 [ "timeout", "3000", "write" ],
178 [ "timeout", "2000", "nip11" ],
179 [ "timeout", "4000", "ssl" ]
180 ```
181 71
182#### Indexed Tags 72Monitors SHOULD also publish a `kind 0` profile and a `kind 10002` relay selections event.
183- `c` "Checks" **SHOULD** be a lowercase string describing the check(s) conducted by a monitor. Due to the rapidly evolving nature of relays, enumeration is organic and not strictly defined. But examples of some checks could be websocket `open/read/write/auth`, `nip11` checks, `dns` and `geo` checks, and and any other checks the monitor may deem useful.. Other checks **MAY** be included. New types of checks **SHOULD** be added to this NIP as they are needed.
184 ```json
185 [ "c", "ws" ],
186 [ "c", "nip11" ],
187 [ "c", "dns" ],
188 [ "c", "geo" ],
189 [ "c", "ssl" ],
190 ```
191 73
192- `g`: `NIP-52` `g` tags (geohash) 74Example:
193 ```json
194 [ "g", "9r1652whz" ]
195 ```
196 75
197- Any other globally defined indexable tags **MAY** be included as found necessary.
198
199### Other Requirements
200Monitors **SHOULD** have the following
201- A published `0` (NIP-1) event
202- A published `10002` (NIP-65) event that defines the relays the monitor publishes to.
203
204### Robust Example of a `10166` Event
205```json 76```json
206{ 77{
207 "id": "<eventid>", 78 "id": "<eventid>",
@@ -209,46 +80,24 @@ Monitors **SHOULD** have the following
209 "created_at": "<created_at [some recent date ...]>", 80 "created_at": "<created_at [some recent date ...]>",
210 "signature": "<signature>", 81 "signature": "<signature>",
211 "content": "", 82 "content": "",
212 "tags": [ 83 "tags": [
213
214 [ "timeout", "open", "5000" ], 84 [ "timeout", "open", "5000" ],
215 [ "timeout", "read", "3000" ], 85 [ "timeout", "read", "3000" ],
216 [ "timeout", "write", "3000" ], 86 [ "timeout", "write", "3000" ],
217 [ "timeout", "nip11", "3000" ], 87 [ "timeout", "nip11", "3000" ],
218
219 [ "frequency", "3600" ], 88 [ "frequency", "3600" ],
220
221 [ "c", "ws" ], 89 [ "c", "ws" ],
222 [ "c", "nip11" ], 90 [ "c", "nip11" ],
223 [ "c", "ssl" ], 91 [ "c", "ssl" ],
224 [ "c", "dns" ], 92 [ "c", "dns" ],
225 [ "c", "geo" ] 93 [ "c", "geo" ]
226
227 [ "g", "ww8p1r4t8" ] 94 [ "g", "ww8p1r4t8" ]
228 ] 95 ]
229} 96}
230``` 97```
231 98
232## Methodology 99 ## Risk Mitigation
233 100
234### Monitors 101 - Clients MUST NOT require `30166` events to function. Absence of monitoring data MUST NOT prevent relay connections.
2351. A _Relay Monitor_ checks the liveness and potentially other attributes of a relay. 102 - A monitor may publish erroneous `30166` events, either by misconfiguration or malicious intent.
236 103 - Clients SHOULD NOT trust a single source. Defenses include: web-of-trust filtering, querying multiple monitors, and discarding filter results if they would remove an unreasonable proportion of relays.
2372. _Relay Monitor_ publishes a kind `30166` note when a relay it is monitoring is online. If the monitor has a `10166` event, events should be published at the frequency defined in their `10166` note.
238
239_Any pubkey that publishes `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_
240
241### Clients
2421. In most cases, a client **SHOULD** filter on `30166` events using either a statically or dynamically defined monitor's `pubkey` and a `created_at` value respective of the monitor's published `frequency`. If the monitor has no stated frequency, other mechanisms should be employed to determine data integrity.
243
2442. _Relay Liveness_ is subjectively determined by the client, starting with the `frequency` value of a monitor.
245
2463. The liveness of a _Relay Monitor_ can be subjectively determined by detecting whether the _Relay Monitor_ has published events with respect to `frequency` value of any particular monitor.
247
2484. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms.
249
250## Risk Mitigation
251
252- When a client implements `NIP-66` events, the client should have a fallback if `NIP-66` events cannot be located.
253
254- A `Monitor` or `Ad-hoc Monitor` may publish erroneous `30166` events, intentionally or otherwise. Therefor, it's important to program defensively to limit the impact of such events. This can be achieved with web-of-trust, reviews, fallbacks and/or data-aggregation for example.