NIP-66: Relay Liveness Monitoring
The relay network needs observability it can publish about itself
Relays are the physical reality of Nostr. They go up, go down, change policies, require payment, require auth, reject kinds, slow down, disappear and come back. Without monitoring, users and clients guess.
NIP-66 defines a way for monitors to publish structured observations about relays as Nostr events. A monitor can probe a relay, compare behavior to its NIP-11 document and publish what it saw. Other clients can use those events for relay discovery, dashboards and routing decisions.
This is not one official uptime oracle. It is a format for competing monitors to describe the relay network.
Discovery events and monitor announcements
Kind 30166 relay discovery events describe a relay. The required d tag is the normalized relay URL or, for non-URL relays, a hex pubkey. Tags can describe open, read and write round-trip time, network type, relay type, supported NIPs, requirements such as auth or payment, topics, accepted or rejected kinds and geohash.
The content may include the relay's NIP-11 document as stringified JSON. That lets people compare advertised policy to measured behavior. The source explicitly allows those to disagree when probes show a relay behaves differently than it claims.
Kind 10166 monitor announcements advertise a monitor's intent to publish relay discovery events regularly. Tags describe frequency, timeout values and checks such as websocket, NIP-11, SSL, DNS or geo checks.
Sandwich and nostr.watch made relay monitoring concrete
Sandwich added the visible Relay Discovery and Liveness Monitoring draft in March 2025. Later 2025 changes cleaned the file and corrected assertions, including the note that tags must not have integers. In March 2026, alltheseas added defensive measures, and in May 2026 fiatjaf made sanity fixes.
nostr.watch is the obvious ecosystem anchor. Its repository describes a TypeScript monorepo for monitoring, auditing and describing relays, and notes OpenSats grant support. Nostrability's interoperability tracker says nostr.watch runs off NIP-66 events, though publication relays have historically been limited.
The history shows a standard tied to actual infrastructure work, not only a wish for dashboards.
A monitor's reputation matters as much as its tags
A monitor implementing NIP-66 needs reliable probes, normalized relay URLs, repeatable measurement intervals and clear tagging. A client consuming NIP-66 must not treat every monitor as equally authoritative. Monitor identity, frequency and methodology matter.
nostr.watch provides the clearest implementation direction: dashboards, agents and library pieces for observing relays and publishing structured results back into Nostr. Other relay monitors can publish the same event shapes and let clients compare.
The product value is large: better relay pickers, broken-relay warnings, capability discovery, auth/payment requirement hints and geographic or network-type filters. But the numbers must be presented as measurements by a monitor, not universal truth.
Monitoring can become a ranking monopoly
Relay monitoring is helpful, but dashboards can shape which relays get used. If one monitor becomes the default truth source, relay discovery can centralize around it.
There is also measurement risk. A relay can look slow from one region and fine from another. It can behave differently under auth, payment or Tor. NIP-66 clients need to show monitor and check context rather than flattening everything into one score.
Read NIP-66 in the wild
NIP-66 turns relay liveness into signed observation. Directories and monitors can record whether relays respond and what behavior they see.
Measurements are evidence, not truth. A monitor has a location, timing, method and bias. Good relay pages show who measured what and when.
What changes when you actually use it
For you, NIP-66: Relay Discovery and Liveness Monitoring is felt when a relay accepts, rejects, indexes, hides, charges for or returns events. Relays are not passive pipes. They make policy and infrastructure choices that shape what a client can show. The source terms kind 0, kind 10002, draft, relay, content, d matter because they are the narrow places where a product can distinguish a relay decision from a network failure.
What changes for builders and operators
For builders and operators, NIP-66: Relay Discovery and Liveness Monitoring is observability. Log what the relay accepted, rejected, counted, authenticated or refused. Then show enough of that to users so they can repair configuration instead of assuming Nostr is empty or broken.
What the official file makes concrete
The official file is organized around Relay Discovery Events, Relay Monitor Announcements. Inspect kind 0, kind 10002, draft, relay, content, d, rtt-read, rtt-write because these are the pieces most likely to surface as product behavior. Read it beside NIP-11, NIP-52 before treating it as isolated.
NIP-66: Relay Discovery and Liveness Monitoring belongs to infrastructure, not scenery. Acceptance, indexing, authentication, retention, payment and filtering all shape what you actually see.
Where it breaks
The failure mode in NIP-66: Relay Discovery and Liveness Monitoring is blaming the network for one server's policy. A relay may reject an event for payment, spam, size, auth, retention or software reasons. If the client collapses those cases into one empty state, the user loses the ability to act.
Where this appears outside the markdown
In the ecosystem, NIP-66: Relay Discovery and Liveness Monitoring lives where users rarely look and operators spend real money: websocket services, relay policies, indexes, rate limits, authentication, monitoring and retention. A good hub page has to make that infrastructure readable because relay behavior decides whether Nostr feels alive, empty, expensive or hostile.
The nearby-standard trap
The nearby-standard trap in NIP-66: Relay Discovery and Liveness Monitoring is treating all relay standards as one reliability story. Discovery, authentication, information documents, search, counts, monitoring and management each expose a different slice of relay behavior. Read NIP-11, NIP-52 before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-66: Relay Discovery and Liveness Monitoring names the relay decision. It says whether access, payment, indexing, search, storage, rate limit, auth or policy shaped the result. That language gives you something to fix instead of making the network feel mystical.
What this page does not promise
NIP-66: Relay Discovery and Liveness Monitoring does not make every relay equal. A relay can be public, paid, local, archival, search-oriented, authenticated, heavily moderated or almost disposable. The standard gives clients and operators a way to communicate one part of that behavior. It does not replace uptime checks, policy reading, payment terms, retention expectations or the practical question of whether your own events can be found later.
Read it as a field test
Start NIP-66: Relay Discovery and Liveness Monitoring with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to kind 0, kind 10002, draft, relay, content, d. A relay NIP becomes readable when it explains what a relay can honestly promise and what still depends on policy, money and operations.
Where the standard earns trust
The source links give you places to test the interpretation in public: nostr.watch repository, nostr.watch README, nostrability NIP-66 tracker, NIP-11 Relay Information. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-66 source is the anchor for exact wording, and NIP-66 commit history shows how that wording moved over time. The strongest secondary clues here are nostr.watch repository, nostr.watch README, nostrability NIP-66 tracker. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-66: Relay Discovery and Liveness Monitoring: first the human promise, then kind 0, kind 10002, draft, relay, content, d, then the implementation record, then the real-world failure case. That order keeps NIP-66 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What exact relay behavior is being described: discovery, auth, search, count, information, payment, moderation or management?
- Can you see whether a failure came from policy, payment, indexing, rate limit, auth or downtime?
- Does the relay expose enough public information for you to decide whether it belongs in your own relay set?
What to verify before you rely on it
- Find
kind 0,kind 10002,draft,relay,contentin the official file and check where the UI exposes the same concept. - Read NIP-11, NIP-52 as context before treating NIP-66 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-66: Relay Discovery and Liveness Monitoring in that order: Official NIP-66 source for the current wording; NIP-66 commit history for the change record; nostr.watch repository, nostr.watch README, nostrability NIP-66 tracker for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
