From a109ea7762ae95ed4b61c52e12e9b65c8aa4c9e7 Mon Sep 17 00:00:00 2001 From: dskvr Date: Fri, 30 Aug 2024 18:19:28 +0200 Subject: [PATCH] language update --- 66.md | 209 +++++++++++++++++++++++++++++----------------------------- 1 file changed, 106 insertions(+), 103 deletions(-) diff --git a/66.md b/66.md index 158ad63b..532ce58c 100644 --- a/66.md +++ b/66.md @@ -8,122 +8,42 @@ In its purest form: ```json { - "sig": "", - "pubkey": "", - "id": "", - "content": "{}", - "created_at": 1722173222, "kind": 30166, + "created_at": 1722173222, + "content": "{}", "tags": [ - [ - "d", - "wss://eostagram.com/" - ] - ] + [ "d", "wss://somerelay.abc/" ] + ], + "pubkey": "", + "sig": "", + "id": "" } ``` -This event signals that the relay at `wss://eostagram.com/` was reported "online" by `` at timestamp `1722173222`. This event **MAY** be extended upon to include more information. +This event signals that the relay at `wss://somerelay.abc/` was reported "online" by `` at timestamp `1722173222`. This event **MAY** be extended upon to include more information. ## Kinds -This NIP defines two (2) event kinds, `10166` and `30166` +`NIP-66` defines two (2) event kinds, `30166` and `10166` | kind | name | description | |-------|----------------------------|-----------------------------------------------------------------------------------------| -| [10166](#k10166) | Relay Monitor Announcement | An RE that stores data to publish intent to monitor and details around their activities | | [30166](#k30166) | Relay Discovery | A PRE that is published by a monitor when a relay is online | +| [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_ | ## Ontology - `Relay Operator`: someone who operates a relay -- `Monitor Service`: a group or individual that monitors relays -- `Monitor`: a piece of software that aggregates relay data and publishes that data at a specified frequency. +- `Monitor`: A pubkey that monitors relays and publishes `30166` events at the frequency specified in their `10166` event. +- `Ad-hoc Monitor`: A pubkey that monitors relays and publishes `30166` events at an irregular frequency. +- `Monitor Service`: A group or individual that monitors relays using one or more `Monitors`. - `Check`: a specific data point that is tested or aggregated by a monitor. -## `10166`: "Relay Monitor Announcement" Events - -### Summary -`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 `NIP-66` events. - -### Purpose -To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities. Absence of the `10166` event is not encouraged, but if absent implies the monitor is ad-hoc and does not publish events at a predictable frequency. - -### Schema - -#### Non-Indexed Tags - -- `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. A `-1` frequency means that the monitor does not publish events at a predictable frequency. - - ```json - [ "frequency", "3600" ] - ``` - -- `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, for example `open`, `read`, `write`, `nip11`, etc. 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_. - ```json - [ "timeout", "2000", "open" ], - [ "timeout", "2000", "read" ], - [ "timeout", "3000", "write" ], - [ "timeout", "2000", "nip11" ], - [ "timeout", "4000", "ssl" ] - ``` - -#### Indexed Tags -- `c` "Checks" **SHOULD** be a lowercase string describing the check(s) conducted by a monitor. Some examples are: `ws`, `nip11`, `ssl`, `dns`, `geo`, etc. Other checks **MAY** be included. New types of checks **SHOULD** be added to this NIP as they are needed. - ```json - [ "c", "ws" ], - [ "c", "nip11" ], - [ "c", "dns" ], - [ "c", "geo" ], - [ "c", "ssl" ], - ``` - -- `g`: `NIP-52` `g` tags (geohash) - ```json - [ "g", "9r1652whz" ] - ``` - -- Any other globally defined indexable tags **MAY** be included as found necessary. - -### Other Requirements -Monitors **SHOULD** have the following -- A published `0` (NIP-1) event -- A published `10002` (NIP-65) event that defines the relays the monitor publishes to. - -### Robust Example of a `10166` Event -```json -{ - "id": "", - "pubkey": "", - "created_at": "", - "signature": "", - "content": "", - "tags": [ - [ "url", "https://a.good.monitor/"], - - [ "timeout", "open", "5000" ], - [ "timeout", "read", "3000" ], - [ "timeout", "write", "3000" ], - [ "timeout", "nip11", "3000" ], - - [ "frequency", "3600" ], - - [ "c", "ws" ], - [ "c", "nip11" ], - [ "c", "ssl" ], - [ "c", "dns" ], - [ "c", "geo" ] - - [ "g", "ww8p1r4t8" ] - ] -} -``` - ## `30166`: "Relay Discovery" ### Summary `30166` is a `NIP-33` Parameterized-Replaceable Event [PRE], referred to as a "Relay Discovery" event. These events are optimized with a small footprint for protocol-level relay Discovery. ### Purpose -Enables the discovery of relays via nostr protocol. +Discovery of relays over nostr. ### Schema @@ -143,7 +63,7 @@ The `created_at` field in a NIP-66 event should reflect the time when the relay _Other `rtt` values **MAY** be present. This NIP should be updated if there is value found in more `rtt` values._ ##### Single Letter Tags (indexed) -- `d` The relay URL. The `#d` tag **must** be included in the `event.tags[]` array. Index position `1` **must** be the relay websocket URL. The URL **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6) +- `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. ```json [ "d", "wss://somerelay.abc/"] ``` @@ -228,20 +148,103 @@ _Relay was online, and you can filter on a number of different tags_ } ``` -#### Methodology +## `10166`: "Relay Monitor Announcement" Events -##### Monitors -1. A _Relay Monitor_ checks the liveness of a relay at the `frequency` defined in their `10166`. +### Summary +`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. -2. _Relay Monitor_ publishes a kind `30166` note when a relay it is monitoring is online. +### Purpose +To 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. -_Relay Monitors that publish `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_ +### Schema -##### Clients -1. In most cases, a client **SHOULD** filter on `30166` events using either a staticly or dynamically chosen monitor's `pubkey` and a `created_at` value respective of the monitor's published `frequency`. +#### Standard Tags + +- `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. + + ```json + [ "frequency", "3600" ] + ``` + +- `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_. + ```json + [ "timeout", "2000", "open" ], + [ "timeout", "2000", "read" ], + [ "timeout", "3000", "write" ], + [ "timeout", "2000", "nip11" ], + [ "timeout", "4000", "ssl" ] + ``` + +#### Indexed Tags +- `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. + ```json + [ "c", "ws" ], + [ "c", "nip11" ], + [ "c", "dns" ], + [ "c", "geo" ], + [ "c", "ssl" ], + ``` + +- `g`: `NIP-52` `g` tags (geohash) + ```json + [ "g", "9r1652whz" ] + ``` + +- Any other globally defined indexable tags **MAY** be included as found necessary. + +### Other Requirements +Monitors **SHOULD** have the following +- A published `0` (NIP-1) event +- A published `10002` (NIP-65) event that defines the relays the monitor publishes to. + +### Robust Example of a `10166` Event +```json +{ + "id": "", + "pubkey": "", + "created_at": "", + "signature": "", + "content": "", + "tags": [ + + [ "timeout", "open", "5000" ], + [ "timeout", "read", "3000" ], + [ "timeout", "write", "3000" ], + [ "timeout", "nip11", "3000" ], + + [ "frequency", "3600" ], + + [ "c", "ws" ], + [ "c", "nip11" ], + [ "c", "ssl" ], + [ "c", "dns" ], + [ "c", "geo" ] + + [ "g", "ww8p1r4t8" ] + ] +} +``` + +## Methodology + +### Monitors +1. A _Relay Monitor_ checks the liveness and potentially other attributes of a relay. + +2. _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. + +_Any pubkey that publishes `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_ + +### Clients +1. In most cases, a client **SHOULD** filter on `30166` events using either a staticly or dynamically chosen 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. 2. _Relay Liveness_ is subjectively determined by the client, starting with the `frequency` value of a monitor. 3. 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. -4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms. \ No newline at end of file +4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms. + +## Risk Mitigation + +- When a client implements `NIP-66` events, the client should have a fallback if `NIP-66` events cannot be located. + +- 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. \ No newline at end of file