Compare commits

...

42 Commits

Author SHA1 Message Date
Sandwich
166552bb8f
Merge cc3d7c63f5 into a1ca7a194b 2024-12-11 09:32:39 +01:00
Jon Staab
a1ca7a194b Change strategy for naming groups 2024-12-10 19:25:28 -03:00
Jesus Christ
e942427f8f
nip17: specify order (#1637)
Order specificity is implied better.
2024-12-09 12:13:59 -03:00
Josh Brown
624b989f9f clarify that Standard lists and Sets are both types of lists with heading level 2024-12-09 12:13:20 -03:00
hodlbod
b35dd7d294
Merge pull request #1635 from AsaiToshiya/update-breaking
Update BREAKING.md
2024-12-09 06:30:47 -08:00
Asai Toshiya
b94ad00ac7 BREAKING.md: add NIP-46 change 2024-12-09 13:29:10 +09:00
Asai Toshiya
d71887a8e2 BREAKING.md: merge duplicate lines 2024-12-09 13:19:16 +09:00
Sandwich
cc3d7c63f5
Fix typos 2024-09-17 19:39:10 +02:00
Sandwich
fa73074f9e
content SHOULD contain stringified NIP-11 2024-09-13 03:25:06 +02:00
dskvr
a109ea7762 language update 2024-08-30 18:19:28 +02:00
dskvr
42c5101834 minor update to k tag that provides support for blocked kinds. 2024-08-29 15:18:39 +02:00
Sandwich
ceabeccb88 draft7 2024-07-30 13:14:15 +02:00
sandwich
f83c49fc39 draft6 2024-02-11 20:25:19 +00:00
sandwich
be0ebd5b34 Fix some typos, improve language, add example 1066 event 2024-01-25 20:12:03 +00:00
sandwich
41feba2746 fix mismatch between schema and example 2024-01-23 19:55:39 +00:00
sandwich
2db9908166 limitations->limitation fix, integer solution, nested obj disclaimed 2024-01-23 19:46:42 +00:00
sandwich
154ffc1a84 changes 2024-01-23 18:52:27 +00:00
sandwich
913dd3a018 Fix formatting 2024-01-16 17:17:28 +00:00
sandwich
26ef08c90b reorganize kinds to be more intuitive 2024-01-12 14:52:48 +01:00
dskvr
b8b07a2659 fix event kind collision 2023-12-30 22:24:03 +01:00
dskvr
9a3c5c0230 add self-reporting 2023-12-30 22:17:31 +01:00
dskvr
1bc98b5cdb fix as/asn tags and verbage for 1066 2023-12-30 20:30:17 +01:00
dskvr
956f8251ac dec-23 update 2023-12-30 11:43:44 +01:00
dskvr
71bd3a0a8f Merge branch 'master' into nip-59-relay-status 2023-12-27 13:48:30 +01:00
dskvr
94da0c1014 NIP-66 Winter-2023 Update 2023-12-27 13:46:01 +01:00
dskvr
29a8acb69a improve g tag and add language for IP data usage 2023-04-12 15:53:46 +02:00
dskvr
6c6251cfb2 fix inconsistency in schema description 2023-03-01 18:03:57 +01:00
dskvr
3b50d3d721 fix typo 2023-03-01 18:01:06 +01:00
dskvr
7316506d97 rename file 2023-03-01 17:51:43 +01:00
dskvr
5c5f08c6ac update language as per discussion 2023-03-01 17:51:26 +01:00
dskvr
7bed3f7223 missing comma 2023-02-11 14:27:08 +01:00
dskvr
31675f04b4 remove comma from last item in array 2023-02-11 14:16:28 +01:00
dskvr
649e40a0b3 fix formatting 2023-02-11 14:15:49 +01:00
dskvr
a86f7dcaae add new tags to example 2023-02-11 14:12:09 +01:00
dskvr
3c2f2c6997 add two new tags and fix some small typos 2023-02-11 14:11:07 +01:00
dskvr
24ed654e4c asc -> desc 2023-02-10 13:44:30 +01:00
dskvr
2d10a628d8 change schema 2023-02-10 13:34:58 +01:00
dskvr
1a154dc1c8 Fix typo 2023-02-07 15:23:50 +01:00
dskvr
3bd4457997 minimal -> minimum 2023-02-07 15:18:46 +01:00
dskvr
2a2fbc3202 Consistent formatting 2023-02-07 15:15:47 +01:00
dskvr
de9e41077c A use case, fix text formatting 2023-02-07 15:12:03 +01:00
Sandwich
4bec3aa1ef NIP-59 Relay status and meta
Simplify language in personas

Fix error in schema example

Fix Iv6
2023-02-07 14:38:33 +01:00
5 changed files with 260 additions and 13 deletions

2
17.md
View File

@ -133,7 +133,7 @@ When sending a message to anyone, clients must then connect to the relays in the
This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.
The two final GiftWraps, one to the receiver and the other to the sender, are:
The two final GiftWraps, one to the receiver and the other to the sender, respectively, are:
```json
{

4
29.md
View File

@ -30,8 +30,6 @@ When encountering just the `<host>` without the `'<group-id>`, clients MAY infer
Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
## Timeline references
In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
@ -242,3 +240,5 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
### Using `unmanaged` relays
To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.

8
51.md
View File

@ -14,7 +14,7 @@ When new items are added to an existing list, clients SHOULD append them to the
## Types of lists
## Standard lists
### Standard lists
Standard lists use normal replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
@ -29,14 +29,14 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |
| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) |
| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |
| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) |
| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) |
## Sets
### Sets
Sets are lists with well-defined meaning that can enhance the functionality and the UI of clients that rely on them. Unlike standard lists, users are expected to have more than one set of each kind, therefore each of them must be assigned a different `"d"` identifier.
@ -56,7 +56,7 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
| Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) |
| Release artifact sets | 30063 | groups of files of a software release | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"` |
## Deprecated standard lists
### Deprecated standard lists
Some clients have used these lists in the past, but they should work on transitioning to the [standard formats](#standard-lists) above.

250
66.md Normal file
View File

@ -0,0 +1,250 @@
# NIP-66: Relay Discovery and Liveness Monitoring
`draft` `optional`
You 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.
In its purest form:
```json
{
"kind": 30166,
"created_at": 1722173222,
"content": "{}",
"tags": [
[ "d", "wss://somerelay.abc/" ]
],
"pubkey": "<pubkey>",
"sig": "<signature>",
"id": "<eventid>"
}
```
This 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.
## Kinds
`NIP-66` defines two (2) event kinds, `30166` and `10166`
| kind | name | description |
|-------|----------------------------|-----------------------------------------------------------------------------------------|
| [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`: 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.
## `30166`: "Relay Discovery" <a id="k30166"></a>
### 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
Discovery of relays over nostr.
### Schema
#### Content
`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.
#### `created_at`
The `created_at` field in a NIP-66 event should reflect the time when the relay liveness (and potentially other data points) was checked.
#### `tags`
##### Meta Tags (unindexed)
- `rtt-open` The relay's open **round-trip time** in milliseconds.
- `rtt-read` The relay's read **round-trip time** in milliseconds.
- `rtt-write` The relay's write **round-trip time** in milliseconds.
_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/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/"]
```
- `n`: Network
```json
[ "n", "clearnet" ]
```
- `T`: Relay Type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`
```json
["T", "PrivateInbox" ]
```
- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
```json
[ "N", "42" ]
```
- `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 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
```json
[ "R", "!payment" ], //no payment required, is public
[ "R", "!auth" ], //no authentication required
```
- `t`: "Topics" _From NIP-11 "Informational Document" `nip11.tags[]`_
```json
[ "t", "nsfw" ]
```
- `k`: Accepted/Blocked Kinds [`NIP-22`]
```json
[ "k", "0" ],
[ "k", "3" ],
[ "k", "10002" ]
```
or for blocked kinds
```json
[ "k", "!0" ]
[ "k", "!3" ],
[ "k", "!10002" ]
```
- `g`: `NIP-52` `g` tags (geohash)
```json
[ "g", "9r1652whz" ]
```
- `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`.
#### Robust Example of a `30166` Event
_Relay was online, and you can filter on a number of different 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", "40"],
["N", "33"],
["R", "!payment"],
["R", "auth"],
["g", "ww8p1r4t8"],
["p", "somehexkey..."],
["l", "en", "ISO-639-1"],
["t", "nsfw" ],
["rtt-open", 234 ]
]
}
```
## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
### 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.
### 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.
### Schema
#### 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": "<eventid>",
"pubkey": "<monitor's pubkey>",
"created_at": "<created_at [some recent date ...]>",
"signature": "<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 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.
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.
## 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.

View File

@ -5,6 +5,7 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2024-12-05 | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
| 2024-11-12 | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |
| 2024-11-12 | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | NIP-05 login was removed |
| 2024-11-12 | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `create_account` method was removed |
@ -30,8 +31,7 @@ reverse chronological order.
| 2024-02-07 | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [46](46.md) | Connection token format was changed |
| 2024-01-30 | [1a2b21b6](https://github.com/nostr-protocol/nips/commit/1a2b21b6) | [59](59.md) | 'p' tag became optional |
| 2023-01-27 | [c2f34817](https://github.com/nostr-protocol/nips/commit/c2f34817) | [47](47.md) | optional expiration tag should be honored |
| 2024-01-10 | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [02](02.md) | list entries should be chronological |
| 2024-01-10 | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [51](51.md) | list entries should be chronological |
| 2024-01-10 | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [02](02.md), [51](51.md) | list entries should be chronological |
| 2023-12-30 | [29869821](https://github.com/nostr-protocol/nips/commit/29869821) | [52](52.md) | 'name' tag was removed (use 'title' tag instead) |
| 2023-12-27 | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [94](94.md) | 'aes-256-gcm' tag was removed |
| 2023-12-03 | [0ba45895](https://github.com/nostr-protocol/nips/commit/0ba45895) | [01](01.md) | WebSocket status code `4000` was replaced by 'CLOSED' message |
@ -46,10 +46,7 @@ reverse chronological order.
| 2023-08-21 | [89915e02](https://github.com/nostr-protocol/nips/commit/89915e02) | [11](11.md) | 'min_prefix' was removed |
| 2023-08-20 | [37c4375e](https://github.com/nostr-protocol/nips/commit/37c4375e) | [01](01.md) | replaceable events with same timestamp should be retained event with lowest id |
| 2023-08-15 | [88ee873c](https://github.com/nostr-protocol/nips/commit/88ee873c) | [15](15.md) | 'countries' tag was renamed to 'regions' |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [12](12.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [16](16.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [20](20.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-14 | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [12](12.md), [16](16.md), [20](20.md), [33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
| 2023-08-11 | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [25](25.md) | empty `content` should be considered as "+" |
| 2023-08-01 | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [57](57.md) | 'zap' tag was changed |
| 2023-07-15 | [d1814405](https://github.com/nostr-protocol/nips/commit/d1814405) | [01](01.md) | `since` and `until` filters should be `since <= created_at <= until` |