NIP-66: Relay Discovery, Liveness and the Reality Check
Relay liveness turns a static relay list into something you can test: is the endpoint alive, reachable, honest about its metadata and useful for the job you need?
Lists age quickly
Relay lists feel solid until you use them for a week. A relay that looked alive yesterday can be gone today. A relay that accepted writes last month can add payment tomorrow. A relay that advertised NIP-50 search can keep the tag in its information document while the search path silently stops working. A relay can move from nostream to strfry, change limits, stop indexing older events, reject bigger queries, lose its contact field, block Tor, add NIP-42 authentication or simply sit behind a bad network route from your city.
That is why static relay lists are dangerous when they are treated as infrastructure truth. They are useful as discovery. They are not enough for operation. If your client ships with ten endpoints and half are overloaded, a new user does not experience "a decentralized protocol." They experience a broken first note, a stuck feed, missing replies and a sense that nothing reliable is underneath the interface. The protocol may be fine. The relay set may be the problem.
NIP-66 exists because the relay layer needs public observation. Nostr already lets people publish notes, relay lists, profile metadata, zap receipts and long-form content. Relay health should be publishable too. Instead of one website keeping a private database of endpoints, a monitor can publish signed observations back into Nostr. Other clients, dashboards and researchers can read those observations, compare monitors and build a fresher view of the relay market.
This sounds dry until you think about daily use. When you open a client, it has to choose where to read, where to write, where to search, where to find your friends, where to load old events and where to send private or wallet-related traffic. Every choice depends on relay reality. A list of URLs tells you where doors might be. Liveness data tells you which doors opened, how long they took and whether the room behind them looked like the sign outside.
The point is not to make Nostr dependent on one monitor. The point is to make relay condition part of the same open event fabric as everything else. If infrastructure is plural, measurement has to be plural too.
What NIP-66 adds
NIP-66 is a draft optional NIP. That status matters. A client must not require it in order to connect to relays, and a relay is not broken merely because no monitor has reported on it. The NIP gives a common event language for relay discovery and monitor announcements. It does not create a central authority, a mandatory registry or a magic ranking system. It creates signed claims that you can inspect, combine, filter and distrust when needed.
The standard has two main event types. Kind 30166 is the relay discovery event. It documents characteristics a monitor inferred from a relay's NIP-11 document or from probing the relay directly. Kind 10166 is the relay monitor announcement. It lets a monitor say: I intend to publish relay discovery events, I run checks at this frequency, I use these timeouts, and I cover these kinds of checks. One event describes relays. The other describes the observer.
That observer layer is the subtle part. If you only see a relay status claim, you still need to ask who made it. Did the monitor run from Europe, North America, mobile networks, Tor, a cloud region, a home connection or several places? Does it test open only, or open plus read plus write plus NIP-11 plus DNS plus TLS? Does it publish hourly, daily or whenever someone remembers? Does it have a profile, a public relay selection event and a track record? NIP-66 gives the ecosystem a way to ask those questions without leaving the protocol.
NIP-66 also accepts that advertised metadata and observed behavior can disagree. NIP-11 is what a relay says about itself. Probing is what a monitor saw. Both can be wrong in different ways. A relay can honestly publish old metadata. A monitor can mis-test a feature. A network route can fail from one region and work from another. The interesting signal is not one field. The interesting signal is the difference between claims, tests and repeated observations over time.
If you use NIP-66 well, you do not ask "which relay is best?" You ask better questions: which relays are alive for my region, support the NIPs my client needs, accept the event kinds I publish, have reasonable latency, match their own metadata, and have enough independent monitor evidence that I am not depending on one noisy source?
Kind 30166 tells you what a monitor saw
A kind 30166 event is a relay discovery event. Its required d tag is the normalized relay URL, such as a wss:// endpoint. If the relay is not accessible through a URL, the standard allows a hex-encoded pubkey instead. That d tag matters because relay URLs are messy in the real world. Trailing slashes, redirects, aliases, mixed schemes and copy-pasted endpoints can fragment monitoring unless everyone agrees what exactly is being described.
The event can include the relay's NIP-11 document as JSON in content. That gives you a snapshot of the relay's self-description at the time the monitor looked. It can also include tags for measured behavior. The rtt-open, rtt-read and rtt-write tags record round-trip timing in milliseconds. The n tag can describe the network type, such as clearnet, tor, i2p or loki. The N tag can list supported NIPs. The R tag can describe requirements that correspond to NIP-11 limitations, including auth, writes, proof-of-work and payment, with a ! prefix for false values.
Those tags turn vague health into structured hints. Instead of "relay seems ok," you can see whether the monitor opened the connection quickly, read from it, wrote to it, saw NIP support, noticed authentication, detected payment requirements or observed accepted event kinds. The k tag can describe accepted and unaccepted kinds. The g tag can carry a geohash when geography matters. The t tag can add topics. The T tag can describe relay type using an enumerated relay-type vocabulary.
The design is intentionally event-native. A monitor signs what it saw. Other clients can collect those events. You can compare several monitors for the same relay. You can ignore monitors you do not trust. You can build dashboards that do not need one private API. You can keep history if you want to see whether a relay degrades every weekend, spikes latency under load or changes policy after a software migration.
Still, a 30166 event is not a verdict. It is a measurement claim. The monitor might have probed poorly. The relay might have treated the monitor differently from normal users. The network path might be unusual. A write test might fail because the monitor used an event kind the relay does not accept. A read test might miss data because the relay has no matching events. Treat 30166 as evidence you can combine, not a score you can obey blindly.
Kind 10166 tells you how the monitor works
Kind 10166 is the relay monitor announcement. It is optional, but it is where responsible monitors can make themselves legible. The event can advertise a publication frequency in seconds, timeout values for checks and the kinds of checks the monitor conducts. A monitor can say it tests open, read, write, auth, NIP-11, DNS, geography or other capabilities. It can publish geohash context. It should also publish a kind 0 profile and a kind 10002 relay selections event so clients know where to find its data.
This matters because monitors are not neutral angels. They run code, from somewhere, with opinions, limits and bugs. A monitor that tests only WebSocket open has a very different value from a monitor that opens, reads, writes, fetches NIP-11, checks DNS, measures latency and audits advertised NIP support. A monitor that runs once a day gives a different signal than one publishing hourly. A monitor with a three-second timeout may mark a slow but usable relay as failing, while a monitor with a fifteen-second timeout may make a sluggish relay look acceptable.
When you see monitor data in a client or dashboard, ask whether the monitor describes itself. Does it say how often it checks? Does it show timeout policy? Does it publish from a stable key? Does it have a profile you can inspect? Does it use a consistent relay selection event for its own publishing? Does it tell you whether it is alpha software, a personal experiment, a public service, a commercial monitor or part of a research project?
The nostr-watch stack is a useful example of where this is going. Its public repository describes a TypeScript monorepo for monitoring, auditing and describing Nostr relays. It includes dashboard code, relay monitoring agents, crawlers, state management, URL normalization, auditing and libraries that can publish or transform NIP-66-style data. That does not make every nostr-watch result automatically correct. It does show the operational direction: relay monitoring is becoming a stack, not a hobby list.
OpenSats framed the same shift clearly when it described NIP-66 work as a way for anyone to publish observations about relay status and for others to read and use that data without depending on one authority. That is the heart of the NIP. Monitoring becomes a Nostr-native market of signed observations.
Liveness is not trust
A relay can be live and still be the wrong choice. It can answer fast while rejecting the event kinds your client needs. It can advertise NIP support while implementing it badly. It can be reachable from a monitor but blocked from your network. It can be online while full of spam. It can accept writes but never retain your events long enough for people to find them. It can serve public notes while being useless for private groups, wallet traffic, search or outbox discovery.
Liveness tells you the endpoint answers. It does not tell you that the operator is careful, that moderation is sane, that privacy is respected, that retention is long enough, that payment terms are fair, that backups exist or that the relay will still be around next month. A live relay is a door that opens. Trust asks what kind of place you entered, who runs it, what they keep, what they drop and whether you can leave cleanly.
That distinction protects you from two opposite mistakes. The first mistake is ignoring liveness because "Nostr is decentralized." Decentralization does not make dead servers work. The second mistake is treating liveness as a ranking of goodness. A fast relay can be wrong for your use case. A slower relay can be excellent for a local group, an archive, a paid inbox or a specialist community. Health checks should inform relay choice, not replace judgment.
Use NIP-66 like weather, not like law. If several monitors say a relay is down, you should not rely on it as your only write target. If several monitors say it is live, you still need to inspect NIP-11 metadata, NIP support, limits, policy and whether your social graph actually uses it. If monitors disagree, that disagreement is useful. It tells you the relay may be regionally flaky, policy-sensitive, rate-limited, hostile to certain checks or simply in a transition.
A good relay page should therefore combine four layers: live status, self-published NIP-11 metadata, observed NIP-66 measurements and human context. Who operates it? What software does it run? What is it for? Is it public, paid, private, local, search, inbox, wallet, archive or group-oriented? Does the relay have a contact address? Does it publish limits? Does it behave the way it advertises?
NIP-11 versus probing
NIP-11 is the relay's own front door sign. It can tell you the relay name, description, contact, supported NIPs, software, version, payments, limitations, fees and policies. Good NIP-11 metadata is a gift to clients because it lets them explain a relay before something fails. But NIP-11 is still self-description. A relay can forget to update it. A relay can claim support for a NIP that is only partly implemented. A relay can omit a payment requirement. A relay can publish old software names after a migration. A relay can be honest and stale at the same time.
Probing is different. A monitor opens a connection, sends requests, tries reads, sometimes tries writes, fetches NIP-11 and records what happened. This can catch reality that metadata misses. A monitor might see that a relay advertises no payment requirement but rejects writes unless payment exists. It might see that a relay advertises NIP-50 search but does not answer search queries properly. It might see that a relay accepts only certain kinds despite a broad description. It might measure that a relay opens fast but read queries are slow.
The best signal comes from the tension between NIP-11 and probing. If metadata and observations agree across several monitors, you can be more confident. If they disagree, do not immediately assume malice. Ask what exactly disagrees. A relay may block write probes to avoid spam. A monitor may use invalid test events. A relay may allow authenticated writes only. A private relay may reject unknown keys by design. A paid relay may require admission before it behaves fully.
That is why NIP-66 includes requirement tags and leaves room for observed details. A monitor should not merely say "failed." It should help you understand whether the failure was open, read, write, auth, DNS, NIP-11, payment, kind support, network type or something else. A client can then turn the signal into a useful sentence instead of a red dot.
If you run a relay, treat monitoring as a mirror. If monitors keep reporting that your advertised NIPs do not match behavior, fix the metadata or the implementation. If they keep timing out on writes, check rate limits and resource pressure. If they cannot fetch your NIP-11 document, your door sign is missing. If they detect a different network shape than you intended, your DNS, proxy or TLS setup may be confusing clients before anyone even sends an event.
Clients can be kinder when they know what failed
Clients are where relay failure becomes human frustration. A protocol-savvy user may open logs, inspect WebSocket messages and recognize that one relay sent NOTICE, another closed the subscription and another timed out. Normal users just see a missing feed. NIP-66 gives clients a chance to turn infrastructure status into kinder explanations.
If a write fails because the relay is down, the client can say the relay appears unreachable and suggest another write relay from your NIP-65 list. If the relay is live but requires auth, the client can start the NIP-42 flow. If the relay is paid, the client can show payment context rather than treating rejection as a crash. If the relay is slow, the client can keep it as a backup instead of making it your first read target. If the relay is a Tor endpoint, the client can explain why it may be slower or unavailable without Tor access.
The first-post experience is the highest-stakes case. Someone installs a Nostr client, creates or imports a key, publishes a note and waits. If the default write relay is dead, the new user has no mental model. They may think the app is broken, their key failed or Nostr has no one inside. A client with liveness awareness can choose healthier defaults, test before writing and show a precise recovery path. That is not a luxury feature. It is the difference between curiosity and abandonment.
Search flows need the same care. NIP-50 relays are specialized. A general relay may be alive but useless for full-text search. A search relay may be alive but stale. A monitor can record supported NIPs, but the client still has to test whether search results are relevant. NIP-66 does not solve search quality, but it helps avoid sending search expectations to endpoints that clearly do not support the job.
Outbox discovery also becomes saner when clients know relay condition. NIP-65 tells clients where a user says they read and write. NIP-66 can help clients avoid dead entries in that map. If your friend publishes their relay list and one relay disappears, a client can still try the list, but it can order attempts intelligently, show degraded status and avoid wasting too long on endpoints that monitors repeatedly mark unavailable.
Operators get a public mirror
Relay operators should welcome good monitoring even when it is uncomfortable. A public relay is not only software. It is DNS, TLS, WebSocket behavior, NIP-11 metadata, database performance, limits, retention, auth policy, payment handling, abuse control and uptime. Monitoring exposes the parts users feel but operators may not notice from inside their own server.
If you operate a relay, start with the basics. Publish a useful NIP-11 document. Include contact information. Name the software and version if you are comfortable doing so. Publish supported NIPs honestly. Publish limitations honestly. If writes are restricted, say so. If auth is required, say so. If payment is required, say so. If max message size, max subscriptions, retention or rate limits matter, expose them. A monitor should not have to reverse-engineer your door sign.
Then test from outside. Can a normal client open the WebSocket? Can it fetch the NIP-11 document over HTTPS? Does the document match actual behavior? Can an unauthenticated user read if reads are public? Can an allowed key write if writes are restricted? Do rejected writes return useful reasons? Does your relay behave consistently after restart? Are paid users differentiated cleanly from unpaid users? Do local or private rules reject outsiders with a policy explanation instead of silent failure?
NIP-66 data can also show how your relay appears in the market. If monitors classify you as a public relay but you meant to be private, your metadata is confusing. If they see payment when your site says free, your policy changed faster than your copy. If they report long open latency, users far from your region may experience your relay as slow even if it feels fine near your server. If they show that you support NIP-42, NIP-50 or NIP-65 differently than advertised, clients may route traffic poorly.
Good operators do not need to satisfy every monitor. They need to make intent and behavior converge. A small local relay can be excellent while intentionally unavailable to random global writes. A paid relay can be excellent while rejecting unpaid users. A private group relay can be excellent while invisible to public directories. Monitoring is useful only when it helps you explain the relay's role truthfully.
Directories grow up from bookmark shelves to evidence desks
Relay directories used to be mostly shelves of URLs. That was useful in the early network, but a mature relay layer needs more. A serious directory should tell you whether a relay is alive, how recently it was checked, what software it runs, which NIPs it advertises, what monitors observed, whether it is paid, whether it requires auth, whether it accepts writes, whether it is public or specialized and whether the directory's own method is transparent.
Nostr Watch, nostr.co.uk relay pages and similar directories are not merely convenience links. They are part of the operating culture of Nostr. They teach users that relays are inspectable infrastructure. They help developers see which NIPs are actually deployed. They help operators compare behavior. They help researchers measure centralization, availability and replication. They help clients choose defaults without hard-coding old assumptions.
But directories also inherit responsibility. If a directory hides its method, you should treat the ranking carefully. If it uses one vantage point, it may overstate or understate global availability. If it does not separate public relays from paid, private, Tor, search, inbox or wallet relays, it can make specialized infrastructure look broken. If it rewards only speed, it may push people toward fast relays that are wrong for their privacy, community or retention needs.
NIP-66 gives directories a cleaner foundation because the observations can be signed, shared and compared. A directory can still add editorial judgment, but it no longer has to pretend that health data lives only in its own database. It can publish and consume Nostr events. That makes relay intelligence portable. Another dashboard can reuse the same monitor events. A client can choose monitors based on trust. A researcher can build historical views without scraping one web page forever.
The best directories will not only show green and red. They will show uncertainty. They will show stale checks. They will show which monitor said what. They will show contradictions between advertised and observed behavior. They will let you filter by role. They will make a paid relay look paid, a private relay look private and a local relay look local instead of flattening every endpoint into one generic score.
Monitor data has its own risk model
NIP-66 includes explicit risk mitigation because monitor data can be wrong. A monitor may be misconfigured. A monitor may have bad network routes. A monitor may misunderstand a relay's policy. A monitor may be malicious. A monitor may publish stale observations. A monitor may run tests that trigger rate limits and then blame the relay. A monitor may classify specialized relays as failures because it expects public behavior.
Clients must not require 30166 events to function. Absence of monitoring data must not prevent relay connections. This is an important rule. A brand-new relay, a private relay, a local event relay or a Tor relay may have no public monitor data and still be exactly what you need. Monitoring should help you make choices, not gate the network.
The NIP also warns against trusting a single source. That is the right instinct. A client can query multiple monitors, filter by web of trust, compare repeated observations and discard results that would remove an unreasonable proportion of relays. That last idea is important. If one monitor suddenly says half the network is unusable, maybe half the network broke. Or maybe the monitor broke. A good client should not turn one noisy source into a mass outage.
There is also a privacy angle. Monitors that probe writes need to publish or attempt events. Monitors that test auth need keys and policies. Monitors that test geography reveal vantage points. Monitors that crawl many relays create observable traffic patterns. None of that is automatically bad, but it means monitor operators should be transparent about what they test and why.
For you, the practical rule is simple: trust monitor data the way you trust weather reports from several stations. If several independent sources agree, act with more confidence. If one source disagrees, inspect. If no source exists, test directly. If the relay matters to your identity, money, group, archive or business process, do not outsource the decision to a badge.
Your relay maintenance routine
You do not need to become a network engineer to use NIP-66 well. You need a small routine. First, keep your personal relay set readable. Know your write relays, read relays, inbox relays, search relays, paid relays, private relays and wallet relays. If everything is one undifferentiated list, you cannot tell what failed when something goes wrong.
Second, check liveness before blaming Nostr. If a note does not propagate, ask whether your write relays are reachable. If replies disappear, ask whether your read relays are healthy and whether the people you follow actually publish there. If search feels empty, ask whether the search relay is live and current. If a wallet flow stalls, ask whether the NWC relay is reachable before assuming the wallet itself failed.
Third, compare liveness with NIP-11. If a relay advertises payment, auth or restricted writes, do not treat those requirements as failures. If it does not advertise them but monitors observe them, slow down. If it advertises NIP support you depend on and probes disagree, test with a second client. If a relay has no contact field, no limits and no clear purpose, use it carefully unless your use case is low risk.
Fourth, remove dead relays from critical paths. You can keep old endpoints in a research list, but your daily write path should not depend on dead bookmarks. Your NIP-65 relay list should represent where people can actually find you. If you move, publish the new list. If you experiment, avoid polluting your main relay list with endpoints you do not intend to maintain.
Fifth, keep backups of meaning, not just URLs. Know why you use each relay. One may be your broad public write relay. One may be where a community reads you. One may be a paid low-spam relay. One may be an archive. One may be a local venue relay. One may be a wallet relay. If a monitor says one is down, the response depends on the job. You do not replace an archive relay the same way you replace a public read relay.
Sixth, weight monitors instead of counting them blindly. A monitor with a clear profile, published relay selections, stable history, disclosed timeout policy and tests from a region close to your use case deserves more attention than an anonymous key that appears once. A monitor that only checks open status should not overrule a monitor that also checks reads, writes, NIP-11 and policy. A monitor that runs from your continent may explain your daily experience better than one on the other side of the world. NIP-66 gives you events, but your client still has to turn those events into judgment.
Finally, treat old measurements as fading evidence. A green status from ten minutes ago is useful. A green status from six weeks ago is a memory. Clients and dashboards should show freshness plainly, expire old observations and avoid caching relay health so aggressively that yesterday's network shape pretends to be today's.
If you run a relay, build the same routine from the operator side. Monitor externally. Watch NIP-11 drift. Test auth and payment flows. Check if public directories classify you correctly. Publish policy changes before users trip over them. Treat monitoring complaints as operational clues, not insults.
The real promise is inspectable infrastructure
Nostr's promise is not that infrastructure disappears. Relays are real servers with operators, costs, software, bugs, policies and regional performance. The promise is that infrastructure can be plural, inspectable, replaceable and user-directed. NIP-66 strengthens that promise because it moves relay observation into the same signed, open event system as the rest of Nostr.
Without liveness data, relay choice becomes folklore. People recommend old endpoints, clients ship stale defaults, users copy big lists and nobody knows which relays are actually useful. With NIP-66, the network can build public memory. Which relays were alive? Which relays changed policy? Which relays contradicted their metadata? Which relays performed well from which vantage points? Which monitors saw the same thing? Which claims aged out?
This does not make Nostr centralized. It does the opposite when used carefully. Instead of one official relay directory, you can have many monitors. Instead of one hidden health API, you can have signed observation events. Instead of one ranking, you can have clients that choose according to your needs: low-latency public posting, paid low-spam writes, local rooms, Tor access, search, archival retention, wallet traffic or venue infrastructure.
The sober version is the useful one. NIP-66 does not tell you which relay deserves your trust. It gives you evidence about which relays exist, respond and behave in certain ways from certain points of view. You still decide. Your client should help. Your relay list should stay intentional. Your operators should publish truthful metadata. Your monitors should be transparent. That is how the relay layer becomes less mystical and more usable.
When you read a relay directory now, look past the green dots. Ask who measured, what they measured, when they measured, what the relay says about itself and what job you need the relay to perform. That is the difference between collecting endpoints and understanding infrastructure.
Sources worth opening
Open these when you want the standard, implementation, monitor or operator trail behind the page.
- NIP-66: Relay Liveness Monitoring
- NIP-66 source on GitHub
- nostr-watch relay monitoring stack
- OpenSats: Advancements in Nostr Relays
- Nostr Watch relay dashboard
- NIP-65: Relay list metadata
- NIP-11: Relay information document
- NIP-50: Search capability
- Nostr Design relay guidance
- nostr.co.uk relay directory
- Exploring the Nostr Ecosystem: decentralization and relay availability study
