mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-09 22:09:06 -05:00
draft6
This commit is contained in:
sandwich
parent
be0ebd5b34
commit
f83c49fc39
696
66.md
696
66.md
|
|
@ -2,201 +2,422 @@
|
|||
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines four event kinds, `10066`, `30066`, `10166` and `1066`.
|
||||
## Table of Kinds
|
||||
This NIP defines three (3) event kinds, `30066`, `30166` and `10166`
|
||||
| kind | name | description |
|
||||
|-------|----------------------------|-----------------------------------------------------------------------------------------|
|
||||
| [10166](#k10166) | Relay Monitor Registration | An RE that stores data to publish intent to monitor and details around their activities |
|
||||
| [30166](#k30166) | Relay Discoverability | A PRE composed of only indexed tags used to discover relays [`d`] |
|
||||
| [30066](#k30066) | Relay Metadata | A PRE composed of human readable, non-indexed tags used to find data on a relay [`d`] |
|
||||
|
||||
## Table of Contents
|
||||
- `10066` [Self-reported Relay Meta](#k10066)
|
||||
- `30066` [Monitor Relay Meta & Status](#k30066)
|
||||
- `10166` [Monitor Meta Data](#k10166)
|
||||
- `1066` [Historical Relay Meta](#k1066)
|
||||
## High Level
|
||||
nostr is a network composed of dumb relays that exhibit different behaviors that are mostly, but not entirely self-reported by their NIP-11 document. However, discoverabililty of relays, and acquiring metadata for relays at the protocol level is not presently implemented. Additionally, self-reported data has an extremely low cieling and is not always reliable.
|
||||
|
||||
## `10066`: "Self-Reported Relay Meta" <a id="k10066"></a>
|
||||
## History
|
||||
- `draft1` implemented in `January 2023` and proposed `February 2023`. "Too many one-letter indexable tags"
|
||||
- `draft2` experimented with `March 2023` "Everything should be expirable"
|
||||
- `draft3` experimented, never proposed
|
||||
- `draft4` experimented, never proposed
|
||||
- `draft5` proposed `December 2023`, "Needs to be indexed"
|
||||
- `draft6` proposed `February 2024`, "Just use one-letter indexable tags" (lol) and split discoverability and parse cases.
|
||||
|
||||
|
||||
## Status
|
||||
Starting in `NIP-66@draft6` **Relay Metadata** and **Relay Discoverability** are considered as two different cases and are split into two different events. However, there remains a pattern for monitors to flag that their `30066` events are indexable.
|
||||
|
||||
## Ontology
|
||||
- `Relay Operator`: someone who operates a relay
|
||||
- `Monitor Service`: a group or individual that monitors the network
|
||||
- `Monitor`: a piece of software that aggregates network data and publishes that data at a specified frequency.
|
||||
- `Check`: a specific data point that is tested or aggregated by a monitor.
|
||||
|
||||
## `10166`: "Relay Monitor Registration" Events <a id="k10166"></a>
|
||||
|
||||
### Summary
|
||||
`10166` is a replacable event herein referred to as "Relay Monitor Registration" 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.
|
||||
|
||||
|
||||
### Kind Usage
|
||||
`NIP-66` kinds can be used by both "Relay Operators" and "Relay Monitors," with the exception that "Relay Operators" **SHOULD NOT** use `10166`
|
||||
|
||||
| Kind | Monitors | Operators |
|
||||
|-------|----------|-----------|
|
||||
| `10166` | x | |
|
||||
| `30066` | x | x |
|
||||
| `30166` | x | x |
|
||||
|
||||
### Schema
|
||||
|
||||
#### Summary
|
||||
|
||||
#### Non-Indexed Tags
|
||||
|
||||
- `url` A URL with human readable information about the monitor's activities. If not included, it is assumed these details are included in the monitor's `website` member in their `kind: 0` JSON for the pubkey that signed the `10066` event.
|
||||
|
||||
- `timeout` The timeout values for various tests. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for, for example `open`, `read`, `write`, `info`, etc. If no index `2` is provided, it is inferred that the timeout provided applies to all tests.
|
||||
```json
|
||||
[ "timeout", "open", "2000" ],
|
||||
[ "timeout", "read", "2000" ],
|
||||
[ "timeout", "write", "3000" ],
|
||||
[ "timeout", "nip11", "2000" ],
|
||||
[ "timeout", "ssl", "4000" ]
|
||||
```
|
||||
|
||||
- `frequency` The frequency at which the monitor publishes events. A string-integer at index `1` represents the frequency **in seconds** of the checks. There should only be `1` frequency per monitor.
|
||||
|
||||
```json
|
||||
[ "frequency", "3600" ]
|
||||
```
|
||||
|
||||
#### Indexed Tags
|
||||
- `k` "Kinds" **should** be a the string-representation of an integer that describes the NIP-66 kinds this monitor publishes. _Note: Kind `10166` **does not** need to be listed here._
|
||||
```json
|
||||
[ "k", "30066" ],
|
||||
[ "k", "30166" ]
|
||||
```
|
||||
|
||||
While `30066` and `30166` have a high-level separation of concerns by Metadata and Discoverability, a monitor can decide to flag `30066` as indexable, and include indexed tags defined in `30166` within their `30066` Relay Metadata events.
|
||||
|
||||
```json
|
||||
[ "k", "30066", "indexed"],
|
||||
```
|
||||
|
||||
- `c` "Checks" **should** be a lowercase string describing the check(s) conducted by a monitor. Some examples are: `rtt`, `nip11`, `ssl`, `dns`, `geo` and `count`. Other checks can be added via consensus.
|
||||
|
||||
```json
|
||||
[ "c", "rtt" ],
|
||||
[ "c", "nip11" ],
|
||||
[ "c", "dns" ],
|
||||
[ "c", "geo" ],
|
||||
[ "c", "dns" ],
|
||||
[ "c", "count" ]
|
||||
```
|
||||
|
||||
- `n` "Counts" **should** be a lower-snake-case string describing the counts(s) conducted by a monitor at index `1`. Some examples are: `total_active_users`, `total_note_zaps`, `total_note_reactions`, `events_per_minute`, `note_publish_rate`. Counts are not atomized, their values are entirely ad-hoc. The time period of the count is defined in `30066`
|
||||
|
||||
```json
|
||||
[ "n", "users_total_active" ],
|
||||
[ "n", "note_total_zaps" ],
|
||||
[ "n", "note_total_reactions" ],
|
||||
[ "n", "note_publish_rate" ]
|
||||
```
|
||||
|
||||
- `o` The hex pubkey of the owner of the monitor. A "Monitor Service" will likely run several monitors.
|
||||
```json
|
||||
[ "o", "b3b0d247f66bf40c4c9f4ce721abfe1fd3b7529fbc1ea5e64d5f0f8df3a4b6e6" ]
|
||||
```
|
||||
|
||||
- `g`: `NIP-66` leverages a draft NIP for geo tags, which is backwards compatible with `0` collisions for legacy `g` tags from `NIP-52`. See [YAGT](https://github.com/nostr-protocol/nips/pull/952)
|
||||
```json
|
||||
[ "G", "countryCode" ]
|
||||
[ "g", "US", "countryCode"]
|
||||
[ "g", "USA", "countryCode" ]
|
||||
[ "G", "regionCode" ]
|
||||
[ "g", "US-CA", "regionCode"]
|
||||
[ "g", "9r1652whz" ]
|
||||
[ "g", "9r1652wh" ]
|
||||
[ "g", "9r1652w" ]
|
||||
[ "g", "9r1652" ]
|
||||
[ "g", "9r165" ]
|
||||
[ "g", "9r16" ]
|
||||
[ "g", "9r1" ]
|
||||
[ "g", "9r" ]
|
||||
[ "g", "9" ]
|
||||
```
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
### Example
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<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" ],
|
||||
[ "c", "count" ],
|
||||
|
||||
[ "n", "total_active_users" ],
|
||||
[ "n", "total_note_zaps" ],
|
||||
[ "n", "total_note_reactions" ],
|
||||
[ "n", "events_per_minute" ],
|
||||
|
||||
[ "k", "30066" ],
|
||||
[ "k", "30166" ],
|
||||
|
||||
["g", "ww8p1r4t8"],
|
||||
["G", "countryCode"],
|
||||
["g", "NL", "countryCode"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## `30166`: "Relay Discoverability" <a id="k30166"></a>
|
||||
|
||||
### Summary
|
||||
`30166` is a `NIP-33` Parameterized-Replaceable Event [PRE], referred to as a "Relay Discoverability" event. These events are optimized with a small footprint for protocol-level relay discoverability, and contain no unindexed tags.
|
||||
|
||||
### Purpose
|
||||
Enables protocol-level discovery of relays on a variety of parameters while ommitting the large footprint of metadata in the "Discovery Case"
|
||||
|
||||
### Schema
|
||||
|
||||
#### Summary
|
||||
`30166` events contain only indexable tags.
|
||||
|
||||
#### Indexed Tags
|
||||
- `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)
|
||||
```json
|
||||
[ "d", "wss://history.nostr.watch/"]
|
||||
```
|
||||
|
||||
- `n`: Network
|
||||
```json
|
||||
[ "n", "clearnet" ]
|
||||
```
|
||||
|
||||
- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
|
||||
```json
|
||||
[ "N", "33" ]
|
||||
```
|
||||
|
||||
- `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_
|
||||
```json
|
||||
[ "R", "payment" ],
|
||||
[ "R", "auth" ],
|
||||
```
|
||||
Since 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
|
||||
|
||||
```json
|
||||
[ "R", "!payment" ], //is public
|
||||
[ "R", "!auth" ], //no auth
|
||||
```
|
||||
|
||||
- `l`: "Language Tags" _From NIP-11 "Informational Document" `nip11.language_tags[]`_
|
||||
```json
|
||||
[ "l", "en" ],
|
||||
[ "l", "en-419" ]
|
||||
```
|
||||
|
||||
- `t`: "Tags" _From NIP-11 "Informational Document" `nip11.tags[]`_
|
||||
```json
|
||||
[ "t", "nsfw" ]
|
||||
```
|
||||
|
||||
- `k`: Accepted Kinds (Only possible with self-reporting until `accepted` and `rejected` kinds are added to NIP-11)
|
||||
```json
|
||||
[ "k", "0" ],
|
||||
[ "k", "3" ],
|
||||
[ "k", "10002" ]
|
||||
```
|
||||
|
||||
- `g`: `NIP-66` leverages a draft NIP for geo tags, which is backwards compatible with `0` collisions for legacy `g` tags from `NIP-52`. See [YAGT](https://github.com/nostr-protocol/nips/pull/952)
|
||||
```json
|
||||
[ "G", "countryCode" ],
|
||||
[ "g", "US", "countryCode"],
|
||||
[ "g", "USA", "countryCode" ],
|
||||
[ "G", "regionCode" ],
|
||||
[ "g", "US-CA", "regionCode"],
|
||||
[ "g", "9r1652whz" ],
|
||||
[ "g", "9r1652wh" ],
|
||||
[ "g", "9r1652w" ],
|
||||
[ "g", "9r1652" ],
|
||||
[ "g", "9r165" ],
|
||||
[ "g", "9r16" ],
|
||||
[ "g", "9r1" ],
|
||||
[ "g", "9r" ],
|
||||
[ "g", "9" ]
|
||||
```
|
||||
|
||||
#### Required Tags
|
||||
In order for discoverability to work as intended, please review the following table.
|
||||
|
||||
| tag | should be set | notes |
|
||||
|-----|----------|--------------------------------------------------------------------------------------------------|
|
||||
| `d` | yes | NIP-33 |
|
||||
| `R` | yes | Required so that public and no-auth relays are discoverable |
|
||||
| `n` | no | |
|
||||
| `N` | no | |
|
||||
| `l` | no | |
|
||||
| `t` | no | |
|
||||
`o` | no | |
|
||||
| `k` | no | |
|
||||
|
||||
#### Example
|
||||
_Relay was online, and you can find it using a bunch of different indexable tags_
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<signature>",
|
||||
"content": "{}",
|
||||
"kind": 30166,
|
||||
"tags": [
|
||||
["d","wss://some.relay/"],
|
||||
["n", "clearnet"],
|
||||
["N", "7"],
|
||||
["N", "33"],
|
||||
["k", "0" ],
|
||||
["k", "3" ],
|
||||
["k", "10002" ],
|
||||
["R", "!payment"],
|
||||
["R", "!auth"],
|
||||
["l", "en"],
|
||||
["l", "es"],
|
||||
["l", "fr"],
|
||||
["g", "ww8p1r4t8"],
|
||||
["G", "countryCode"],
|
||||
["g", "NL", "countryCode"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Tag availability mapping
|
||||
When a monitor flags check support [`c` tag] in their `10166` kind, related indexable fields **SHOULD** be present in their published `30166` event kinds.
|
||||
|
||||
| check | indexable tags |
|
||||
|-------|-----------------|
|
||||
| rtt | n/a |
|
||||
| nip11 | `N` `R` `l` `t` |
|
||||
| ssl | n/a |
|
||||
| dns | n/a |
|
||||
| geo | n/a |
|
||||
|
||||
##### Important Notes
|
||||
- Relay Monitors that publish `30166` events **SHOULD** at a minimum be conducting `rtt` checks, namely websocket `open`, so that clients can determine liveness.
|
||||
- `k` indexable tags are not associated to any other standard and thus cannot be flagged for support in `10166` until `NIP-11` support kind flagging.
|
||||
|
||||
## `30066`: "Relay Metadata" <a id="k30066"></a>
|
||||
|
||||
### Summary
|
||||
An event that contains data about a relay. These events are self-reported by relays from the `owner` pubkey defined in their Information Document (`NIP-11`). Hereinafter referred to as "Relay Meta" events
|
||||
`30066` is a `NIP-33` Parameterized-Replaceable Event [PRE], referred to as a "Relay Metadata" event. These events store the existence and optionally some data relating to the relay. These events can be published by a monitor or self published by relay operators
|
||||
|
||||
### Purpose
|
||||
An event published by a relay owner that makes the owner's relay discoverable.
|
||||
### Purpose
|
||||
To store useful, computationally expensive data derived from checks and other metadata about relays. This data is found by filtering the normalized relay URL with the `d` tag. Determining liveness `30066` can be used by filtering against `since` with respect to the `frequency` value set in a **Relay Monitor's** `10166` event kind.
|
||||
|
||||
### Schema
|
||||
|
||||
#### `event.content`
|
||||
**Should** be empty.
|
||||
`content` **MAY** contain stringified `NIP-11` JSON, since the `NIP-11` cannot be serialized into tags with any sane patterns.
|
||||
|
||||
#### `event.tags`
|
||||
"Self-Reported Relay Meta" events have **one** (1) required tag.
|
||||
|
||||
"Self-Reported Relay Meta" events have **two** (2) non-standard, NIP-66 specific indexable tags.
|
||||
|
||||
Tags should be used to represent the Relay's abilities and meta at any given point in time. The "tags schema" is expressed using pseudo-types for reasons of communication and brevity, for example `tagDescriptor[]`. This NIP utilizes `NIP-32` to expose indexable values.
|
||||
##### Summary
|
||||
1. "Relay Metadata" events have **one** (1) required tag
|
||||
2. **Unindexed Tags** use grouping by defining the _group_ at index position `1`, the key at index position `2` and the value at index position `3`.
|
||||
|
||||
#### Tags
|
||||
- `"r" == tagId[0]` The relay URL. The `#d` tag **must** be included in the `event.tags[]` array. `tagId[1]` **must** be the relay websocket URL. The URL **should** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6)
|
||||
#### Indexed Tags
|
||||
- `d` The relay URL. The `#d` tag **MUST** be included in the `event.tags[]` array. Index position `1` **SHOULD** be the relay websocket URL. The URL **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6)
|
||||
```json
|
||||
[ "d", "wss://history.nostr.watch/"]
|
||||
```
|
||||
["d", "wss://history.nostr.watch/"] //tagId[]
|
||||
- `30066` events **MAY** contain any of the indexable tags included in `30166` kind events (See instructions for this case in `10166`'s schema, specifically under `k`)
|
||||
#### Unindexed Tags
|
||||
- `rtt` group contains key/value pairs that describe the round trip time of a particular operation. Values at position `2...` **SHOULD** treated as an array by consumers. This array can be used to **mathematically** find `min`, `max`, `average` and `median` values. For example `Math.min(...["190", "201", "540"].map( n => parseInt(n) ))`. Some obvious index `1` keys are websocket `open`, `read` and `write` round-trip times, as well as `nip11` https request round-trip time.
|
||||
```json
|
||||
["rtt", "open", "190", "201", "540"],
|
||||
["rtt", "read", "35"],
|
||||
["rtt", "write", "701"]
|
||||
```
|
||||
|
||||
- `n`: Such as `clearnet`, `tor`, `i2p`, `cjdns`, etc _in the context of **NIP-66 only**_
|
||||
```
|
||||
[ "n", "clearnet" ]
|
||||
- `ssl` group contains key/value pairs that describe the checked status of a relay's SSL Certificate. Index `1` keys for `ssl` can be atomized and should be one of the following `valid_from`, `valid_to`, `subject_alt_name`, `fingerprint`, `fingerprint256`, `fingerprint512`, `ext_key_usage`, `exponent`, `serial_number`, `modulus` and/or `pem_encoded`. There **SHOULD NOT** be duplicate keys.
|
||||
```json
|
||||
["ssl", "valid_from", "<timestamp_seconds>"],
|
||||
["ssl", "valid_to", "<timestamp_seconds>"]
|
||||
```
|
||||
|
||||
- `desc == tagDesc[0]` The `description` from relay's NIP-11 information document.
|
||||
```
|
||||
[ "desc", "A nostr relay" ]
|
||||
- `dns` group contains key/value pairs that describe a DNS lookup for the relay from the perspective of a given monitor. It can provide insights on other meta data in the event. Index `1` keys for `dns` can be atomized and should be one of the following `as`, `asn`, `ipv4` or `ipv6`. There **MAY** be duplicate keys.
|
||||
```json
|
||||
["dns", "asn", "19281"],
|
||||
["dns", "as", "QUAD9-AS-1, CH"],
|
||||
["dns", "ipv4", "1.1.1.1"],
|
||||
["dns", "ipv6", "2001:db8:3333:4444:5555:6666:7777:8888"]
|
||||
```
|
||||
|
||||
- `name == tagname[0]` The `name` member from relay's NIP-11 information document.
|
||||
- `nip11` group is a special group that extracts specific values as long as they are no more than 1 level deep and do not contain arrays of objects. This data **MAY** be duplicated as stringified `NIP-11` JSON in content.
|
||||
```json
|
||||
["nip11", "name", "A nostr relay"],
|
||||
["nip11", "description", "It stores notes and other stuff"],
|
||||
["nip11", "owner", "<pubkey:hex>"],
|
||||
["nip11", "software", "<software>"],
|
||||
["nip11", "version", "<version>"]
|
||||
```
|
||||
[ "desc", "A nostr relay" ]
|
||||
For arrays
|
||||
```json
|
||||
["nip11", "supported_nips", "3", "33"],
|
||||
```
|
||||
|
||||
- `N`: Supported NIPs _in the context of **NIP-66 only**_
|
||||
```
|
||||
[ "N", "1" ]
|
||||
[ "N", "11" ]
|
||||
[ "N", "33" ]
|
||||
- `count` Meta values for arbitrary counts related to a relay. Index position `1` is the value expressed as the string representation of an integer or float. Index position `2` is the key and describes the count, such as `total_users` or `total_events`. Index position `3` **MAY** be set and defines the "period" in seconds that the count at position `2` was calculated. Counts **SHOULD** only be included when representing unique or computationally expensive counts, not ones that can be easily achieved via `NIP-45` counts. A count's key **SHOULD** be **snake case**. There **MAY** be zero (0) to many count tags.
|
||||
|
||||
```json
|
||||
["count", "users_total_active", "201", "86400"],
|
||||
["count", "note_total_zaps", "87", "86400"],
|
||||
["count", "note_total_reactions", "125", "86400"],
|
||||
["count", "note_publish_rate", "24.1", "3600"]
|
||||
```
|
||||
|
||||
- `"count" == tagCount[0]` Meta values for arbitrary counts related to a relay. `tagCount[1]` is the value expressed as the string representation of an integer or float. `tagCount[2]` is the key and describes the count, such as `total_users` or `total_events`. Counts **should** only be included when representing unique or computationally expensive counts, not ones that can be easily achieved via `NIP-45` counts. A count's key should be **snake case**. There **may** be zero (0) to many count tags.
|
||||
|
||||
```
|
||||
["count", "502341", "total_events"],
|
||||
["count", "52000", "total_users"],
|
||||
["count", "321", "active_users_24h"]
|
||||
["count", "21.4", "events_per_minute"]
|
||||
- `other`: A group for other type checks that could be a derivative of another check or unassociated to a specific check. A good example is `network` which is is determined by parsing the URL to attempt to identify which network it can be found on, and would likely already be in the monitor's cache as it was determined for discoverability purposes.
|
||||
```json
|
||||
["other", "network", "clearnet"]
|
||||
```
|
||||
|
||||
- `"infohash" == tagInfohash[0]` A SHA256 hash of the deterministically stringified `NIP-11` "Info Document" JSON at `tagInfohash[1]`
|
||||
```
|
||||
[ "infohash", "8332f76d1fbbd3c83abc8eeb5cac296fb7514b9b06d8734f98c16c246d6ec590" ]
|
||||
```
|
||||
#### Tag Usage
|
||||
For self-reported `30066` events by "Relay Operators", certain tags **SHOULD NOT** be self-published or otherwised ignored by clients if present. Please reference the table below.
|
||||
|
||||
#### Label Tags <sup>NIP-32</sup>
|
||||
- `relay_type`, for example `proxy`, `bridge` and `public`. There **may** be more than one type. _Please note,_ at time of writing there has been no collective effort to atomize relay types, so these values cannot be enumerated.
|
||||
```
|
||||
[ "L", "relay_type" ]
|
||||
[ "l", "proxy", "relay_type" ]
|
||||
[ "l", "public", "relay_type" ]
|
||||
```
|
||||
|
||||
- `ipv4`/`ipv6`, relay ips.
|
||||
```
|
||||
[ "L", "ipv4" ]
|
||||
[ "l", "1.1.1.1", "ipv4" ]
|
||||
[ "L", "ipv6" ]
|
||||
[ "l", "2001:db8:3333:4444:5555:6666:7777:8888"", "ipv6" ]
|
||||
```
|
||||
|
||||
- `as`/`asn` the relay ISPs "Autonomous System (Number)"
|
||||
```
|
||||
[ "L", "as" ]
|
||||
[ "l", "QUAD9-AS-1, CH", "as" ]
|
||||
[ "L", "asn" ]
|
||||
[ "l", "19281", "asn" ]
|
||||
```
|
||||
|
||||
- String values from `NIP-11` using dot notation, for example
|
||||
```
|
||||
[ "L", "nip11.tags" ]
|
||||
[ "l", "sfw-only", "nip11.tags" ]
|
||||
[ "l", "bitcoin-only", "nip11.tags" ]
|
||||
[ "L", "nip11.language_tags" ]
|
||||
[ "l", "en", "nip11.language_tags" ]
|
||||
[ "l", "en-419", "nip11.language_tags" ]
|
||||
```
|
||||
|
||||
- Boolean values from `NIP-11`, for example
|
||||
```
|
||||
[ "L", "nip11.limitation" ]
|
||||
[ "l", "payment_required", "nip11.limitation" ] //nip11.limitation payment_required==true
|
||||
[ "l", "auth_required", "nip11.limitation" ] //nip11.limitation auth_required==true
|
||||
```
|
||||
|
||||
#### NIP-11 Integer Values
|
||||
Any NIP-11 values that are integers **should not** be included as NIP-32 labels, instead NIP-11 integer vlaues should use the `nip11` tag.
|
||||
|
||||
```
|
||||
[ "nip11", "65535", "limitation.max_message_length" ]
|
||||
```
|
||||
|
||||
#### NIP-11 Nested Objects
|
||||
NIP-11 nested objects are not supported by NIP-66 at this time (For example, fees)
|
||||
|
||||
#### Geo tags <sup>NIP-YAGT</sup>
|
||||
- `NIP-66` leverages a draft NIP for geo tags, see [YAGT](https://github.com/nostr-protocol/nips/pull/952)
|
||||
```
|
||||
[ 'G', 'countryCode' ]
|
||||
[ 'g', 'US', 'countryCode']
|
||||
[ 'g', 'USA', 'countryCode' ]
|
||||
[ 'g', '840', 'countryCode' ]
|
||||
[ 'G', 'regionCode' ]
|
||||
[ 'g', 'US-CA', 'regionCode']
|
||||
[ 'g', '9r1652whz' ]
|
||||
[ 'g', '9r1652wh' ]
|
||||
[ 'g', '9r1652w' ]
|
||||
[ 'g', '9r1652' ]
|
||||
[ 'g', '9r165' ]
|
||||
[ 'g', '9r16' ]
|
||||
[ 'g', '9r1' ]
|
||||
[ 'g', '9r' ]
|
||||
[ 'g', '9' ]
|
||||
```
|
||||
|
||||
#### Topic Tags
|
||||
- `NIP-66` leverages topics [`t` tags] and optionally adds values at positions `tag[2]` and `tag[3]`. If `tag[2]` is set, it **should** be a string-integer representing the number of tags on the relay. If `tag[2]` is set, `tag[3]` **should** be set and be a string-integer representing the timeframe **in seconds** for the value set as `tag[2]`. This tag is used to indicate topics relevant to the relay through event analysis (as oppossed to 'tags' from `NIP-11` document)
|
||||
|
||||
```
|
||||
["t", "meme", "69", "3600"]
|
||||
```
|
||||
|
||||
## `30066`: "Relay Status" Events <a id="k30066"></a>
|
||||
|
||||
### Summary
|
||||
`30066` is a parameterized replaceable event [NIP-33], referred to as a "Relay Status" event. These events store the existence and optionally some data relating to the relay.
|
||||
|
||||
### Purpose
|
||||
To store useful, computationally expensive relay meta-data about relays. `30066` should be used to give a canonical reference to the last known functional state of a relay, to be evaluated subjectively by a client and/or user to derive conclusions from.
|
||||
|
||||
### NIPs Used
|
||||
- `NIP-32` Labels
|
||||
- `NIP-33` Parameterized Replacable Events
|
||||
- `NIP-40` Expirable Events
|
||||
- [YAGT](https://github.com/nostr-protocol/nips/pull/952) _draft_
|
||||
|
||||
### Schema
|
||||
`30066` inherit the schema from `10066`, with a substitution and some additional tags.
|
||||
|
||||
_**Different referencial tag**_
|
||||
|
||||
- `30066` uses a `d` tag instead of an `r` tag for the normalized relay URL since it is a Parameterized-Replaceable Event
|
||||
|
||||
_**It adds some additional tags**_
|
||||
|
||||
- `"rtt" == tagRtt[0]` Round-trip time of websocket ping/pong in milliseconds. Example values for `tagRtt[1]` are `open`, `read` and `write`. Where `open` represents the round-trip time forWebsocket to open, `read` represents the round-trip time of a Websocket `REQ` (subscription) message's response, and `write` represents the round-trip time of a Websocket `EVENT` (publish) message and subsequent `ok` message. `tagRtt[2...]` are strings with the millisecond values. At a minimum `tagRtt[2]` **should** be set. When more than one value is provided, values **may** be treated as an array to find `min`, `max`, `average` and `median` values. There **may** be zero `rtt` tags.
|
||||
|
||||
```
|
||||
["rtt", "open", "201", "190", "540"],
|
||||
["rtt", "read", "35", "60", "46"],
|
||||
["rtt", "write", "701", "497", "508"]
|
||||
```
|
||||
| | Monitor | Relay Operators |
|
||||
|----------|---------|-----------------|
|
||||
| rtt | x | |
|
||||
| nip11 | x | x |
|
||||
| dns | x | x |
|
||||
| geo | x | x |
|
||||
| ssl | x | |
|
||||
| count | x | x |
|
||||
| other | x | x |
|
||||
|
||||
#### Methodology
|
||||
A Relay Monitor publishes `30066`` events exclusively when a relay is operational. This approach ensures that the last known active state of the relay is maintained and recorded. Based on this data, several inferences can be drawn about the relay's status and characteristics
|
||||
A _Relay Monitor_ publishes `30066` events exclusively when a relay is reachable. This approach ensures that the last known active state of the relay is maintained and recorded in `created_at` value of event. Based on this data, several inferences can be drawn about the relay's status and characteristics.
|
||||
|
||||
1. Clients and/or users can set a custom threshold to establish a cutoff timestamp for filtering events using `since`. This timestamp helps in identifying which relays are currently online. Selecting a lower threshold value results in a stricter criterion for relay uptime, making the filter more sensitive to brief downtimes. Conversely, choosing a higher threshold value creates a more lenient filter, allowing relays with longer downtimes to still be considered as online.
|
||||
|
||||
2. In determining whether a relay is 'dead,' the decision is solely at the discretion of the client or user. The are responsible for setting and applying arbitrary thresholds using `until` filters or post-processing to make this determination. This approach underscores that the classification of a relay as 'dead' is a subjective decision, varying according to each client's or user's assessment criteria, rather than a fixed status provided by the monitor.
|
||||
|
||||
3. For relay status events that have become outdated, the retained data points remain valuable. They offer insights and information about the relay's characteristics and performance, which might not be currently accessible due to the relay being offline.
|
||||
3. For [Relay Metadata](#k30066) events that have become outdated, the retained data points remain valuable. They offer insights and information about the relay's characteristics, performance and impact on the network, which might not be currently accessible due to the relay being offline.
|
||||
|
||||
#### Important Notes
|
||||
- `NIP-11` values are provided as means to filter and discover relays, however **should not** be used as a replacement to `NIP-11`.
|
||||
- A particular relay's retention policy could conflict with subjective thresholds used in determination of "online" or "dead" relays and so care should be taken with regards to chosen relays by both monitors and consumers.
|
||||
- Relay Monitors **SHOULD** run checks and publish events according to the `frequency` value set in their respective `10166` kind event.
|
||||
- If a relay monitor publishes both `30166` and `30066` kind events, they **SHOULD** publish both on every check.
|
||||
- Clients **SHOULD** only use monitors reporting `rtt` values for websockets (particularly `open`) for determining the "liveness" or "deadness" of a relay.
|
||||
- Clients **SHOULD** consider the `frequency` value in a monitor's `10166` when trying to reach determination of "liveness".
|
||||
- `NIP-11` values are provided as means to filter and discover relays, however ****SHOULD NOT** be used as a replacement to `NIP-11`.
|
||||
- A particular relay's retention policy could conflict with subjective thresholds used in determination of "liveness" or "deadness" of relays and so care **SHOULD** be taken with regards to chosen relays for `NIP-66` by both monitors and consumers.
|
||||
|
||||
#### Examples
|
||||
|
||||
##### Minimum Requirements, "Relay was online at `Date(created_at)`"
|
||||
##### Minimum Requirements
|
||||
_"Relay was online at `<created_at>`"_
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
|
|
@ -211,53 +432,53 @@ A Relay Monitor publishes `30066`` events exclusively when a relay is operationa
|
|||
}
|
||||
```
|
||||
|
||||
##### Relay is checked and online example, "Relay is online and here's some meta-data this monitor believes is accurate"
|
||||
##### Relay is checked and online
|
||||
_"Relay was online at <created_at> and here's some meta-data this monitor believes is accurate"_
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"created_at": "<created_at>",
|
||||
"signature": "<signature>",
|
||||
"content": "{}",
|
||||
"content": "{\"contact\":\"pablof7z.com\",\"description\":\"Nostr's Purple Pages\",\"name\":\"purplepag.es\",\"pubkey\":\"fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52\",\"software\":\"git+https://github.com/hoytech/strfry.git\",\"supported_nips\":[1,2,4,9,11,12,16,20,22,28,33,40],\"version\":\"0.9.6-7-g7196547\"}",
|
||||
"kind": 30066,
|
||||
"tags": [
|
||||
["d","wss://some.relay/"],
|
||||
["n", "clearnet"]
|
||||
["N", "1"],
|
||||
["N", "7"],
|
||||
["rtt", "open", "201", "190", "540"],
|
||||
["rtt", "read", "35", "60", "46"],
|
||||
["rtt", "write", "701", "497", "508"],
|
||||
["ssl", "valid", "timestamp", "timestamp"],
|
||||
["count", "21.4", "events_per_minute"],
|
||||
["g", "ww8p1r4t8"],
|
||||
["G", "countryCode"]
|
||||
["g", "NL", "countryCode"],
|
||||
["L", "ipv4"],
|
||||
["l", "1.1.1.1", "ipv4" ],
|
||||
["L", "ipv6"],
|
||||
["l", "2001:db8:3333:4444:5555:6666:7777:8888", "ipv6"],
|
||||
["L", "nip11.tags" ],
|
||||
["l", "sfw-only", "nip11.tags" ],
|
||||
["l", "bitcoin-only", "nip11.tags" ]
|
||||
["L", "nip11.language_tags" ],
|
||||
["l", "en", "nip11.language_tags" ],
|
||||
["l", "en-419", "nip11.language_tags" ],
|
||||
["nip11", "65535", "limitation.max_message_length" ]
|
||||
["other", "network", "clearnet"]
|
||||
["rtt", "open", "190", "201", "540"],
|
||||
["rtt", "read", "35"],
|
||||
["rtt", "write", "701"],
|
||||
["nip11", "name", "A nostr relay"],
|
||||
["nip11", "description", "It stores notes and other stuff"],
|
||||
["nip11", "owner", "<pubkey:hex>"],
|
||||
["nip11", "software", "<software>"],
|
||||
["nip11", "version", "<version>"],
|
||||
["ssl", "valid_from", "<timestamp>"],
|
||||
["ssl", "valid_to", "<timestamp>"],
|
||||
["geo", "geohash", "ww8p1r4t8"],
|
||||
["geo", "countryCode", "NL"],
|
||||
["dns", "asn", "19281"],
|
||||
["dns", "as", "QUAD9-AS-1, CH"],
|
||||
["dns", "ipv4", "1.1.1.1"],
|
||||
["dns", "ipv6", "2001:db8:3333:4444:5555:6666:7777:8888"],
|
||||
["count", "users_total_active", "201", "86400"],
|
||||
["count", "note_total_zaps", "87", "86400"],
|
||||
["count", "note_total_reactions", "125", "86400"],
|
||||
["count", "note_publish_rate", "24.1", "3600"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Testing Criteria
|
||||
The testing criteria to determine conditions defined in event's tags **may** be subjective and **may** vary between monitors.
|
||||
The testing criteria to determine conditions defined in event's tags **MAY** be subjective and **MAY** vary between monitors.
|
||||
|
||||
#### Limitations
|
||||
The data in `30066` **may** be erroneous, intentionally or otherwise. Where accuracy is required, the data in `30066` events **should** be subscribed to by populating the `authors` filter array with the poublic keys of trusted **monitors** and where security or privacy is a concern any republished values (such as NIP-11 values) should instead be attained from the source. All data is for informational purposes and to make finding and filtering through relays through nostr a possiblity.
|
||||
The data in `30066` **MAY** be erroneous, intentionally or otherwise. Where accuracy is required, the data in `30066` events **SHOULD** be subscribed to by populating the `authors` filter array with the public keys of subjectively **trusted monitors** and where security or privacy is a concern any republished values (such as NIP-11 values) should instead be attained from the source (https). All data is for informational purposes and to make finding and filtering through relays through nostr a possiblity.
|
||||
|
||||
#### Ammending NIP-66
|
||||
## Ammending NIP-66
|
||||
Any test results that cannot be expressed through `NIP-66` **should** be ammended to the nip following discussion and general consensus
|
||||
|
||||
### Use Cases
|
||||
## Use Cases
|
||||
1. **Geographic Relay Discovery**: Identify relays situated near a specific geographic location or within a particular country, facilitating localized network interactions.
|
||||
|
||||
2. **NIP Support Filtering**: Search for relays based on their support for specific Nostr Improvement Proposals (NIPs), ensuring compatibility with desired protocol features.
|
||||
|
|
@ -276,109 +497,4 @@ Any test results that cannot be expressed through `NIP-66` **should** be ammende
|
|||
|
||||
9. **Language and Content Filtering**: Identify relays catering to specific languages or content types, enabling users to engage in a more targeted and relevant social networking experience.
|
||||
|
||||
10. **Data-Driven Relay Selection**: Make informed choices about which relays to connect to, based on comprehensive metadata including user counts, event frequencies, network types and more.
|
||||
|
||||
## `10166`: "Relay Monitor" Events <a id="k10166"></a>
|
||||
|
||||
### Summary
|
||||
`10166` is a replacable event herein referred to as "Relay Monitor" events. These events contain information about a publisher's intent to monitor and/or aggregate relays and publish data as `30066` events.
|
||||
|
||||
### Purpose
|
||||
To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities.
|
||||
|
||||
### Schema
|
||||
`10166` events have no required tags.
|
||||
|
||||
- `"url" == tagUrl[0]` A URL with human readable information about the monitor's activities. If not included, it is assumed these details are included in the monitor's kind 0 for the pubkey that signed the `10066` event.
|
||||
|
||||
- `"timeout" == tagTimeout[0]` The timeout values for various tests. `tagTimeout[1]` is the monitor's timeout in milliseconds. `tagTimeout[2]` describes what test the timeout is used for, for example `open`, `read`, `write`, `info`, etc. If no `tagTimeout[2]` is provided, it is inferred that the timeout provided applies to all tests.
|
||||
```
|
||||
[ "timeout", "2000", "open" ]
|
||||
[ "timeout", "2000", "read" ]
|
||||
[ "timeout", "3000", "write" ]
|
||||
[ "timeout", "2000", "nip11" ]
|
||||
```
|
||||
|
||||
- `"kind === tagKind[0]"` The kind(s) this monitor publishes.
|
||||
```
|
||||
[ "kind", "30066" ]
|
||||
[ "kind", "1066" ]
|
||||
```
|
||||
|
||||
- `"frequency" == tagFrequency[0]` The frequency at which the monitor publishes events. A string-integer at `tagFrequency[1]` represents the frequency **in seconds** a event kind is published. The string-integer at `tagFrequency[2]` represents the kind bound to the frequency. If `tagFrequency[2]` is undefined, it is inferred the timeout applies to all events published by the monitor. A frequency **should not** be created for this kind [`1006`]. If a kind is referenced in `tagFrequency` that is not set in `tagKind` it should be disregarded.
|
||||
```
|
||||
[ "frequency", "3600", "30066" ]
|
||||
[ "frequency", "3600", "1066" ]
|
||||
```
|
||||
|
||||
#### Label Tags <sup>NIP-32</sup>
|
||||
|
||||
- `checks` **should** be a lowercase string describing the check(s) conducted by a monitor. Some examples are: `websocket`, `nip11`, `ssl`, `dns`, `geo`
|
||||
|
||||
```
|
||||
[ "L", "checks" ]
|
||||
[ "l", "websocket", "checks" ]
|
||||
[ "l", "nip11", "checks" ]
|
||||
[ "l", "ssl", "checks" ]
|
||||
[ "l", "dns", "checks" ]
|
||||
[ "l", "geo", "checks" ]
|
||||
```
|
||||
|
||||
#### Geo tags <sup>NIP-YAGT</sup>
|
||||
- Kind `10166` leverages a draft NIP for geo tags, see [YAGT](https://github.com/nostr-protocol/nips/pull/952)
|
||||
|
||||
### 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.
|
||||
|
||||
### Example
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<signature>",
|
||||
"content": "{}",
|
||||
"tags": [
|
||||
[ "url", "wss://bob.some.guy"],
|
||||
|
||||
[ "L", "checks" ],
|
||||
[ "l", "websocket", "checks" ],
|
||||
[ "l", "nip11", "checks" ],
|
||||
|
||||
[ "kind", "30066" ],
|
||||
[ "kind", "1066" ],
|
||||
|
||||
[ "frequency", "3600", "30066" ],
|
||||
[ "frequency", "3600", "1066" ],
|
||||
|
||||
[ "timeout", "5000", "open" ],
|
||||
[ "timeout", "3000", "read" ],
|
||||
[ "timeout", "3000", "write" ],
|
||||
[ "timeout", "2000", "nip11" ],
|
||||
|
||||
["g", "ww8p1r4t8"],
|
||||
["G", "countryCode"],
|
||||
["g", "NL", "countryCode"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## `1066`: "Relay Status History" Events <a id="k1066"></a>
|
||||
|
||||
### Summary
|
||||
`3066` is a standard nostr event, referred to as a "Relay Status History" event. These events store the history of a relay at the periodic interval defined in the monitor's `10166`.
|
||||
|
||||
#### Schema
|
||||
Relay History events can contain any of the tags defined for kind `30066`. The `d` tag should be included in every `3066` event, as it can be used to filter historical events by relay URL.
|
||||
|
||||
#### Special Considerations
|
||||
- These events can potentially demand a lot of disk space if not used wisely.
|
||||
|
||||
#### Guidelines
|
||||
Tags representing less-volatile values, for instance `nip11.software` vs `rtt`, contained with this event should only be included when their respectiive values have changed compared to the last Relay History event of the same `d` tag. If there have been no changes, then the event should not be published.
|
||||
|
||||
##### Use Cases
|
||||
- Generate a time series from one or data-point(s) for a specific relay.
|
||||
- Generate network-wide aggregated statistics
|
||||
10. **Data-Driven Relay Selection**: Make informed choices about which relays to connect to, based on comprehensive metadata including user counts, event frequencies, network types and more.
|
||||
Loading…
Reference in New Issue
Block a user