NIPs nostr improvement proposals

NIP-66: Relay Discovery and Liveness Monitoring - Kinds

Table of Contents

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:

{

  "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 Relay Discovery An addressable event that is published by a monitor when a relay is online
10166 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

30166: "Relay Discovery"

Summary

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.

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)

Other rtt values MAY be present. This NIP should be updated if there is value found in more rtt values.

Single Letter Tags (indexed)

Robust Example of a 30166 Event

Relay was online, and you can filter on a number of different tags

{

  "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

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

Indexed Tags

Other Requirements

Monitors SHOULD have the following

Robust Example of a 10166 Event

{

  "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