Relay Liveness Monitoring

Overview

NIP-66 answers a question that gets more awkward the longer Nostr grows: how do you find out which relays are actually working, without asking one company?

Relay directories have historically been websites with an API. That is a sensible way to start and a poor way to finish, because it reintroduces exactly the single point of failure the protocol exists to remove. If the directory goes down, or changes its API, or decides which relays to list, then relay discovery has a gatekeeper again.

NIP-66 moves that data onto Nostr itself. Monitors probe relays and publish what they find as signed Nostr events, which any client can read from any relay.

Why It Matters

The practical consequence is that relay health becomes ordinary protocol data rather than a service you depend on.

• A client can discover working relays without hardcoding a directory URL.
• Multiple monitors can publish about the same relay, and disagree, which is a feature rather than a bug.
• The data is signed, so you know which monitor produced a claim and can weight it accordingly.
• If a monitor disappears, others keep publishing. Nothing breaks.

This is the same structural argument Nostr makes about identity, applied to infrastructure metadata.

Relay Discovery Events (kind 30166)

The core of the spec. A 30166 event describes one relay, based either on its NIP-11 document or on active probing.

The only required tag is d, set to the relay’s normalized URL. Everything else is optional, which keeps the barrier to publishing low.

Tag	Meaning
d	The relay’s normalized URL (required)
rtt-open	Round-trip time to open a connection, in milliseconds
rtt-read	Round-trip time for a read
rtt-write	Round-trip time for a write
n	Network type: clearnet, tor, i2p or loki
T	Relay type, in PascalCase, for example PrivateInbox
N	A NIP the relay supports (repeated per NIP)
R	A requirement from NIP-11 limitations: auth, writes, pow, payment. A ! prefix negates it, so !auth means auth is not required
t	A topic associated with the relay
k	Accepted event kinds, with ! for unaccepted
g	A geohash for the relay’s location

Tags with multiple values are repeated rather than combined, so [["t","cats"],["t","dogs"]] and not [["t","cats","dogs"]].

The content field may carry the relay’s full NIP-11 document as stringified JSON.

{
  "kind": 30166,
  "pubkey": "<monitor's pubkey>",
  "content": "<optional NIP-11 document>",
  "tags": [
    ["d", "wss://some.relay/"],
    ["n", "clearnet"],
    ["N", "40"],
    ["N", "33"],
    ["R", "!payment"],
    ["R", "auth"],
    ["g", "ww8p1r4t8"],
    ["t", "nsfw"],
    ["rtt-open", "234"]
  ]
}

One subtlety worth noting: a monitor’s findings may contradict what a relay advertises in its NIP-11 document. That is deliberate. If a relay claims to accept writes without auth but actually rejects them, the monitor reports what it observed, not what it was told.

Relay Monitor Announcements (kind 10166)

Optional, and aimed at monitors that intend to run on a predictable schedule. A 10166 event announces that a pubkey publishes 30166 events, and describes how it operates.

• frequency: how often, in seconds, the monitor publishes
• timeout: the timeouts used for its checks, optionally scoped to a named check
• c: the checks it performs, such as open, read, write, auth, nip11, dns or geo
• g: a geohash for where the monitor runs

Monitors should also publish a kind 0 profile and a NIP-65 kind 10002 relay list, so they are discoverable in the ordinary way.

Risk Mitigation

The spec is unusually direct about its own failure modes, and the guidance is worth following literally.

• Clients MUST NOT require 30166 events to function. Missing monitoring data must never stop a client connecting to a relay.
• A monitor can be wrong, through misconfiguration or malice.
• Clients SHOULD NOT trust a single source. The suggested defences are web-of-trust filtering, querying several monitors, and discarding a filter result if it would remove an implausible proportion of relays.

That last defence is the interesting one. It is a sanity check against a monitor that has itself broken: if applying its data would wipe out most of your relay list, the more likely explanation is that the monitor is faulty rather than that the network died overnight.

Practical Notes

If you maintain a relay list or directory, NIP-66 is the supported way to get an independent second opinion on liveness. Query 30166 events filtered by the d tag for the relay you care about, compare monitors, and treat a single monitor’s silence as weak evidence rather than proof.

Note also what NIP-66 does not do. It does not rank relays, it does not certify them, and it carries no authority. It is a way for observers to publish observations. Deciding what to do with those observations stays with the client, which is the correct place for it.

Related NIPs

• NIP-11: the relay information document monitors read
• NIP-65: how users publish their own relay preferences
• NIP-51: lists, including relay sets
• NIP-01: the base protocol these events are built on