nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-12 15:09:07 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix some typos, improve language, add example 1066 event

Browse Source
This commit is contained in:
sandwich 2024-01-25 20:12:03 +00:00
parent 41feba2746
commit be0ebd5b34
1 changed files with 76 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

112
66.md
View File

@ -4,14 +4,19 @@
This NIP defines four event kinds, `10066`, `30066`, `10166` and `1066`.
## 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)
## `10066`: "Self-Reported Relay Meta"
## `10066`: "Self-Reported Relay Meta" <a id="k10066"></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
### Purpose
An event that makes relays discoverable.
An event published by a relay owner that makes the owner's relay discoverable.
### Schema
@ -19,9 +24,9 @@ An event that makes relays discoverable.
**Should** be empty.
#### `event.tags`
"Relay Meta" events have **one** (1) required tag.
"Self-Reported Relay Meta" events have **one** (1) required tag.
"Relay Meta" events have **two** (2) non-standard, NIP-66 specific indexable tags.
"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.
@ -36,7 +41,12 @@ Tags should be used to represent the Relay's abilities and meta at any given poi
[ "n", "clearnet" ]
```
- `desc == tagDesc[0]` The description from nip11.
- `desc == tagDesc[0]` The `description` from relay's NIP-11 information document.
```
[ "desc", "A nostr relay" ]
```
- `name == tagname[0]` The `name` member from relay's NIP-11 information document.
```
[ "desc", "A nostr relay" ]
```
@ -48,22 +58,22 @@ Tags should be used to represent the Relay's abilities and meta at any given poi
[ "N", "33" ]
```
- `"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. There **may** be zero (0) to many count tags.
- `"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", "total_events", "502341"],
["count", "total_users", "52000"],
["count", "active_users_24h", "321"]
["count", "events_per_minute", "21.4"]
["count", "502341", "total_events"],
["count", "52000", "total_users"],
["count", "321", "active_users_24h"]
["count", "21.4", "events_per_minute"]
```
- `"infohash" == tagInfohash[0]` A SHA256 hash of the deterministically stringified `NIP-11` "Info Document" JSON at `tagInfohash[1]`
```
[ "infohash", "fj89as0n3inmcd89nefkdlsky2mfkdlsfds" ]
[ "infohash", "8332f76d1fbbd3c83abc8eeb5cac296fb7514b9b06d8734f98c16c246d6ec590" ]
```
#### Label Tags <sup>NIP-32</sup>
- `relay_type`, for example `proxy`, `bridge` and `public` for example. There **may** be more than one type. There have not been efforts to atomize relay types at the time of writing this NIPs, so these values cannot be enumerated at this time.
- `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" ]
@ -104,7 +114,7 @@ Tags should be used to represent the Relay's abilities and meta at any given poi
```
#### NIP-11 Integer Values
Any NIP-11 values that are integers should not be included as NIP-32 labels, instead they should use the `nip11` tag.
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" ]
@ -117,9 +127,9 @@ NIP-11 nested objects are not supported by NIP-66 at this time (For example, fee
- `NIP-66` leverages a draft NIP for geo tags, see [YAGT](https://github.com/nostr-protocol/nips/pull/952)
```
[ 'G', 'countryCode' ]
[ 'g', 'US', 'countryCode', 'alpha-2' ]
[ 'g', 'USA', 'countryCode', 'alpha-3' ]
[ 'g', '840', 'countryCode', 'numeric' ]
[ 'g', 'US', 'countryCode']
[ 'g', 'USA', 'countryCode' ]
[ 'g', '840', 'countryCode' ]
[ 'G', 'regionCode' ]
[ 'g', 'US-CA', 'regionCode']
[ 'g', '9r1652whz' ]
@ -134,14 +144,13 @@ NIP-11 nested objects are not supported by NIP-66 at this time (For example, fee
```
#### 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 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)
- `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)
```
//69 events with "meme" topic in the last hour
["t", "meme", "69", "3600"]
```
## `30066`: "Relay Status" Events
## `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.
@ -156,7 +165,7 @@ To store useful, computationally expensive relay meta-data about relays. `30066`
- [YAGT](https://github.com/nostr-protocol/nips/pull/952) _draft_
### Schema
`30066` events are almost identical to `10066` except a few key differences.
`30066` inherit the schema from `10066`, with a substitution and some additional tags.
_**Different referencial tag**_
@ -172,7 +181,6 @@ _**It adds some additional tags**_
["rtt", "write", "701", "497", "508"]
```
#### 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
@ -196,6 +204,7 @@ A Relay Monitor publishes `30066`` events exclusively when a relay is operationa
"created_at": "<created_at>",
"signature": "<signature>",
"content": "",
"kind": 30066,
"tags": [
["d","wss://some.relay/"]
]
@ -210,6 +219,7 @@ A Relay Monitor publishes `30066`` events exclusively when a relay is operationa
"created_at": "<created_at [some recent date ...]>",
"signature": "<signature>",
"content": "{}",
"kind": 30066,
"tags": [
["d","wss://some.relay/"],
["n", "clearnet"]
@ -242,9 +252,9 @@ A Relay Monitor publishes `30066`` events exclusively when a relay is operationa
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 pubkeys 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 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.
#### Appending 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
@ -268,7 +278,7 @@ Any test results that cannot be expressed through `NIP-66` **should** be ammende
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
## `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.
@ -286,12 +296,7 @@ To provide a directory of monitors, their intent to publish, their criteria and
[ "timeout", "2000", "open" ]
[ "timeout", "2000", "read" ]
[ "timeout", "3000", "write" ]
[ "timeout", "2000", "info" ]
```
- `"ssl" == tagSsl[0]` SSL certificate check. `tag[1]` is either `valid` or `invalid`. `tag[2]` is the validate start date. `tag[3]` is the validity end date. Can include reference via `e` or `a` to raw SSL data for indepdent validation.
```
["ssl", "valid", "timestamp", "timestamp"],
[ "timeout", "2000", "nip11" ]
```
- `"kind === tagKind[0]"` The kind(s) this monitor publishes.
@ -300,7 +305,7 @@ To provide a directory of monitors, their intent to publish, their criteria and
[ "kind", "1066" ]
```
- `"frequency" == tagFrequency[0]` The frequency at which the monitor publishes events. A string-integer at `tagFrequency[1]` represents the frequency 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" == 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" ]
@ -320,18 +325,53 @@ To provide a directory of monitors, their intent to publish, their criteria and
```
#### 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)
- Kind `10166` leverages a draft NIP for geo tags, see [YAGT](https://github.com/nostr-protocol/nips/pull/952)
### Other Requirements
- Monitors **should** have a published `10002` event that defines the relays the monitor publishes to.
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.
## `1066`: "Relay Status History" Events
### 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
`1066` is a standard nostr event, referred to as a "Relay Status History" event. These events store the history of a relay at a periodic interval (defined in `10166`).
`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` (Including the `d` tag which is used to filter these events by relay). There is one new indexable tag
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.