Relay counts, liveness and the problem with counting Nostr infrastructure
The relay ecosystem is not a stadium scoreboard. Counting relays can help you understand resilience, but only if you separate raw endpoints from living, useful, reachable and policy-clear infrastructure.
Counting is hard because relays are not a single species
A Nostr relay is easy to name and hard to count. You can collect URLs from public lists, relay monitors, client defaults, NIP-65 relay lists, search engines, GitHub docs and old blog posts. You will quickly get a large number. Then the number starts falling apart. Some endpoints are dead. Some are aliases. Some require payment. Some require authentication. Some are private. Some reject writes. Some are search-only. Some are wallet-only. Some are local. Some exist for tests. Some respond once and vanish.
That does not mean counting is useless. It means the first number is only the beginning. If you say "there are thousands of relays," you have not yet said whether Nostr is healthy. You have said that you found many URLs that might have been relays at some point. Health requires a sharper question: which relays are alive, usable, diverse and relevant to actual routing?
The temptation is understandable. Big numbers feel reassuring. They make decentralization visible. But a network with many dead relays and a few important defaults can still be fragile. A network with fewer relays but good diversity, clear policies, healthy liveness, good client routing and strong personal/local options can be more resilient than a giant stale list.
Relay counts should therefore be read like weather, not like scripture. They are snapshots from a method. The method matters. Who collected the relays? From where? How recently? Did the collector test WebSocket connections? Did it fetch NIP-11? Did it distinguish public, private, paid and auth-required? Did it remove duplicates? Did it test supported NIPs? Did it measure real usage?
If you cannot answer those questions, treat the count as a rough map. Useful, but not final.
What counts as a relay?
The simplest answer is an endpoint that speaks the Nostr relay protocol. But practical counting needs categories. A public read/write relay is different from a read-only archive. A paid write relay is different from a free public relay. A private group relay is different from a broad public firehose. A wallet relay is different from a social relay. A search relay is different from a storage relay. A local venue relay is different from a global default.
If your count includes all of them without labels, the number becomes mush. It may still show ecosystem experimentation, but it does not tell you how many relays a normal user can publish to, how many support search, how many are alive, how many support NIP-65, how many require auth, how many are local, or how many store history.
Aliases also complicate the count. A relay may be reachable through multiple domains or paths. A domain may redirect. A relay may publish a Tor address. A project may move endpoints. If you count URLs, you may overcount infrastructure. If you count operators, you need to know ownership. If you count unique software instances, you need fingerprints that may not be public. Each metric answers a different question.
Time windows matter too. A relay that was alive once in the last month is different from a relay that responds every hour. A relay that is down during one monitor check may be recovering. A relay that is up but rejects all writes is alive but not broadly usable. Counting needs timestamps and status categories.
A strong relay directory should treat "relay" as a record with fields, not just a line in a list: URL, status, last seen, NIP-11 metadata, software, supported NIPs, read/write policy, auth, payment, limits, operator contact, geography if known, and monitor confidence.
Liveness is necessary, not enough
Liveness asks whether a relay can be reached and responds. That matters. A dead relay cannot serve your profile, notes, relay list or group state. If your client depends on dead relays, your Nostr experience becomes slow and confusing. Monitoring liveness is one of the most practical things the ecosystem can do.
But liveness is not quality. A relay can be alive and spammy. Alive and hostile. Alive and stale. Alive and narrow. Alive and no longer accepting writes. Alive and missing NIP-11 metadata. Alive and slow from your region. Alive and requiring payment you do not have. Alive and irrelevant to your follows. A green dot should not be worshipped.
Quality depends on role. For a public write relay, you care about uptime, moderation, spam resistance, accepted event kinds, limits and reach. For an archival relay, you care about retention, storage, search and sync. For a wallet relay, you care about narrow event support, privacy, auth and reliability. For a local relay, you care about membership, room rules and local continuity. One metric cannot judge them all.
Latency also has context. A relay can be fast from a monitor in one region and slow for users elsewhere. A relay can respond quickly to NIP-11 and slowly to subscriptions. A relay can be fast for small queries and bad for historical range queries. Good monitoring separates connection, metadata, read, write, search and subscription behavior when possible.
Use liveness as a gate, not a verdict. Is it alive? Good. Now ask what kind of alive.
NIP-66 turns relay observation into protocol data
NIP-66 describes relay discovery and liveness monitoring events. It gives the ecosystem a way to publish structured observations about relays instead of relying only on off-protocol web directories. That matters because relay health changes constantly. The network needs current signals, not only static lists.
A monitor can publish information about relay URLs, observed metadata, liveness, supported NIPs and other measurements. Clients and directories can use those observations to improve relay selection. If several independent monitors agree that a relay is dead, a client can warn users. If a relay advertises NIP-50 search support and monitors confirm it, search UI can use that signal.
The monitor itself becomes a trust object. Who runs it? How often does it check? From which network? Which relays does it know? How does it handle auth-required, paid, Tor, local or private relays? Does it publish errors or only green/red states? Does it keep history? NIP-66 gives a structure, but measurement quality still depends on the monitor.
Multiple monitors are better than one. If only one monitor's data shapes client behavior, the monitor becomes a hidden gatekeeper. With several monitors, clients can compare, users can spot disagreement and directories can avoid treating one viewpoint as global truth. Relay liveness is healthiest when measured pluralistically.
Nostr Watch is important because it made relay visibility tangible for many users and builders. It also shows the broader lesson: directories and monitors are not side quests. They are infrastructure for understanding the infrastructure.
Public, private and paid relays should not be counted the same way
A public relay count answers one question: how many endpoints might a broad user be able to use? A private relay count answers another: how much local or member infrastructure exists? A paid relay count answers another: how much sustainable access infrastructure is emerging? A wallet relay count answers yet another: how much specialized payment-related relay infrastructure exists?
If a report counts private relays as if they were public capacity, it overstates open reach. If it excludes private and local relays entirely, it understates ecosystem depth. If it counts paid relays as unavailable, it misses sustainable infrastructure. If it counts them as free public relays, it misleads users. The category is part of the metric.
Private and local relays may be invisible to public monitors by design. That does not make them unimportant. A conference relay, cafe relay, team relay or family relay can be central to the people who use it while irrelevant to public counts. The public map is not the whole city.
Paid relays may respond differently to unauthenticated probes. A monitor might mark them as restricted, paid, auth-required or partially reachable. That distinction is useful. A paid relay that is alive but rejects unpaid writes is not dead. It is gated. A directory should say gated, not failed.
Good counts should therefore provide layers: known relay URLs, currently reachable relays, public write relays, public read relays, auth-required relays, paid relays, private/local relays where visible, search relays, archival relays, wallet relays and dead or stale entries. The exact categories can evolve, but the principle is stable: separate the jobs.
Software and geography reveal hidden concentration
Relay diversity is not only the number of URLs. It is also software diversity, operator diversity, hosting diversity and geography. If many important relays run the same software, a bug or performance issue can spread. If many sit behind the same cloud provider, provider pressure can spread. If many are operated by the same people, social pressure can spread. If many are in one jurisdiction, legal pressure can spread.
NIP-11 can expose software name and version, but not every relay fills it honestly or consistently. Still, software metadata is useful. Seeing strfry, nostr-rs-relay, nostream, Khatru, Grain, custom relays and app-specific relays in the wild tells you something about implementation diversity. One software stack winning everything would be convenient and risky.
Geography is harder. Relays may use CDNs, cloud regions, proxies, Tor addresses or hosting that hides operator location. You do not always need exact geography, but you should care about concentration. If all your important relays sit in one legal and infrastructure environment, you have a common failure mode.
Operator diversity matters most and is hardest to measure. Ten relay URLs run by one operator are not the same as ten relays run by ten communities. A directory may not know ownership, but users can look for contact, domain patterns, software, policy pages and community context.
Better relay counts should therefore avoid declaring victory from URL count alone. Ask: how many independent operators? How many software stacks? How many funding models? How many jurisdictions? How many client defaults? How many user communities? That is where resilience actually lives.
Client dependency is the count users actually feel
A relay can exist and be healthy, but if no clients use it, normal users do not feel it. A client can also depend heavily on a small relay set while thousands of other relays exist unused. The user experience follows client routing more than abstract relay abundance.
This is why NIP-65 relay lists and outbox discovery matter. They let the network route toward authors' chosen relays instead of relying only on client defaults. But client implementation decides whether that promise is real. A client that ignores relay lists makes the network feel smaller than it is. A client that respects them makes relay diversity usable.
Client dependency can be measured by asking which relays are bundled as defaults, which relays are queried for search, which relays are used for onboarding, which relays clients write to automatically and which relays appear in many users' NIP-65 lists. That tells you where soft centralization may be happening.
Counts should separate "available infrastructure" from "used infrastructure." Both matter. Available relays show potential resilience. Used relays show practical power. If the gap is huge, the ecosystem may be decentralized on paper but centralized in habit.
As a user, you can make the gap smaller by choosing relays intentionally, publishing a good NIP-65 list, using clients that respect outbox discovery and supporting relays that fit your needs. Relay diversity becomes real when routing uses it.
Better metrics for a healthier relay map
A better relay report would start with raw known URLs, then filter into current reachability, recent liveness, public read, public write, auth-required, paid, private or local, supported NIPs, search support, relay-list support, software, limits, contact, policy and last-seen timestamp. That sounds like more work because it is more work. It is also more honest.
Useful metrics include median uptime over a window, successful NIP-11 fetch rate, write acceptance for a test key, read query success, max limit behavior, supported NIPs, software diversity, default-client concentration, NIP-65 occurrence, search support, auth/payment indicators and policy visibility. Each metric answers a specific question.
Bad metrics flatten everything. "X relays online" with no method. "Largest relay list" with no dedupe. "Decentralized because many relays" with no usage data. "Reliable because green" with no role or policy. These numbers are easy to share and easy to misunderstand.
For researchers, methodology should be visible. Date, collector, source lists, probe method, timeout, regions, supported NIP checks, duplicate handling, auth/payment classification and limitations. Nostr research is young enough that sloppy counts can become folk wisdom quickly. Better to be careful now.
For product builders, the most useful metrics are user-facing: which relays make this account work? Which are slow? Which are dead? Which reject writes? Which require auth? Which are good for search? Which are good for archive? Which are local? Which are paid? Your UI can turn network metrics into user agency.
Your relay-count routine
When you see a relay count, ask what was counted. URLs, live endpoints, public write relays, monitored relays, relays in user lists, relays in client defaults or relays supporting a specific NIP? The number changes with the question.
When you choose relays, do not chase the largest list. Pick roles. A few healthy public relays for reach. A paid or trusted relay if you need cleaner writes. A personal or local relay if you need your own memory. Search relays for discovery. Archival relays for long-term work. Wallet relays only for wallet context. Counts inform the map; roles build the route.
When a relay fails, check liveness before assuming policy. If it is alive, check auth and payment. If it is reachable, check supported event kinds. If it has metadata, read limits. If another client sees the event, your client may be routing badly. Failure diagnosis is a better skill than memorizing a giant list.
If you run a relay, make yourself countable in useful ways. Publish NIP-11. Include contact. State supported NIPs and limits. Explain auth, payment and policy. Let monitors see what they can see. If your relay is private, say so where appropriate. The more legible your relay is, the more accurately the ecosystem can map itself.
The mature takeaway is simple: count relays, but do not worship counts. Measure liveness, but do not worship green dots. Look for diversity, role clarity and user routing. That is where relay health becomes real.
Common measurement traps
The first trap is stale list inflation. A relay URL found in an old README, client config, pastebin, GitHub list or archived directory may remain in counts long after the server died. Nostr moves quickly. A relay list without last-seen data is not a health report. It is a historical artifact.
The second trap is endpoint duplication. A relay may appear with and without a trailing slash, through a root domain and a subdomain, through clearnet and Tor, or through an old and new URL. If you count strings, you overcount. If you dedupe too aggressively, you may merge distinct services. The safest approach is to keep aliases visible and state the dedupe method.
The third trap is probe bias. A monitor running from one region, one network, one timeout and one client library will see a particular world. Some relays may reject that probe, require auth, be slow from that location, block data centers or expose different behavior to real clients. A monitor is a vantage point, not an omniscient narrator.
The fourth trap is treating write success as universal. A relay may accept a simple kind 1 note but reject long-form content, group events, wallet events, large media metadata or search filters. A write test proves one event kind at one moment. It does not prove the relay supports your use case.
The fifth trap is counting relays but ignoring users. Ten thousand obscure endpoints do not help much if most users publish to five defaults. Counting NIP-65 occurrences, client defaults and actual routing behavior helps reveal practical concentration. The user graph and the relay graph must be read together.
What a good probe should test
A useful relay probe begins gently. Can the endpoint open a WebSocket? Does it respond within a reasonable timeout? Can the monitor fetch the NIP-11 information document over HTTP with the correct accept header? Does the metadata parse? Does it list supported NIPs? Does it show software, limits, contact, payment or auth requirements?
Then the probe can test read behavior. Can the relay answer a simple subscription? Does it return an EOSE message? Does it handle limits correctly? Does it support old event ranges? Does it close subscriptions cleanly? Does it behave differently for common event kinds? Read behavior matters because many relays may be useful as archives or inboxes even if writes are restricted.
Write behavior should be tested with care. A monitor should not spam public relays with junk events. If it publishes test events, it should use a clearly identified key, small payloads and cleanup where appropriate. It should respect paid, auth-required and private relays. It should not mark a relay "bad" simply because it refuses unauthenticated writes when its metadata says that is policy.
Search behavior should be separate. Does the relay advertise NIP-50? Does a simple search return relevant results? Does the relay support extensions? Does it return results ordered usefully? A relay can be excellent for storage and bad for search, or excellent for search and not intended for writes.
Liveness history matters more than a single ping. A relay that is alive 99 percent of checks is different from one that blinks alive once a week. A directory should show last seen, recent uptime and maybe trend. Users need to know whether the relay is stable or merely not dead right now.
Reading NIP-11 as a count filter
NIP-11 metadata is one of the best ways to turn raw relay counts into useful categories. If a relay publishes supported NIPs, you can separate basic relays from search relays, auth relays, group relays, liveness-related relays and management-capable relays. If it publishes limitations, you can see max message size, max subscriptions, max filters, payment requirements and other constraints.
Contact metadata matters. A relay with a contact path is not automatically better, but it is easier to treat as operated infrastructure rather than abandoned machinery. If something breaks, users or clients can at least discover a route to the operator. A relay with no contact, no description and no limits may still be useful, but it gives the ecosystem less information.
Software metadata reveals implementation diversity. If many important relays run the same software, monitoring should notice. If a new relay implementation appears, directories can help it become visible. If a relay hides software, that may be fine for security or privacy reasons, but it limits ecosystem analysis.
Payment and auth metadata help avoid false negatives. A monitor that marks a paid relay as failing because writes were rejected is not reading the room. NIP-11 can tell the monitor and client that payment or auth is expected. Good counts classify gated relays instead of throwing them into dead or broken buckets.
Metadata also ages. A relay can change policy without updating NIP-11. A monitor should compare observed behavior with advertised metadata. If a relay says it supports a NIP but does not respond as expected, that mismatch is a useful signal. If it requires auth but does not advertise it, that is a usability issue.
Counts for different readers
A normal user needs a small, practical count: how many of my chosen relays are alive, how many accepted my last event, how many serve my profile, how many are slow, and which ones matter for the people I follow? A global relay count is interesting, but the personal route matters more day to day.
A client developer needs a different count: which relays support the NIPs my product depends on, which are good defaults for onboarding, which return useful errors, which support outbox discovery well, which are stable across regions, and which should never be silently hardcoded as universal truth?
A relay operator needs peer counts: how many relays with similar purpose exist, which software stacks are common, what limits others publish, how paid relays present policy, which event kinds are usually accepted, and how monitors classify relays like mine. That helps operators benchmark without copying blindly.
A researcher needs methodology counts: corpus size, source lists, probe schedule, dedupe rules, event kinds, liveness windows, geographic vantage points, and missing data. Without that, a research claim about Nostr infrastructure can sound precise while resting on a fragile collection process.
A community organizer needs local counts: how many relays carry this community's events, which ones are controlled by the community, which are third-party dependencies, which can be restored, and which client defaults hide or expose the community. For a local room, resilience is not global relay abundance. It is the continuity of that room.
Personal relay health is the count you can act on
Open your own client and look at relay status. How many write relays do you use? How many read relays? Are any dead? Does your profile appear on more than one relay? Does your contact list appear? Does your relay list itself appear? If a new client logs in with your key, can it rebuild your world?
Then test one publish. Which relays accepted it? Which rejected it? Which timed out? Did any return auth-required, restricted, rate-limited, blocked or invalid? A personal publish report is more valuable than a global relay number because it tells you whether your setup actually works.
Test one old event. Can another client fetch it? Can a search relay find it? Can replies load? Is it stored on only one relay? If your important history depends on one endpoint, you may want an archival or personal relay strategy. Counting your own copies is a very practical form of decentralization.
Test one follow. Pick someone you care about and inspect their relay list. Does your client route to their write relays? Are those relays alive? If not, you may miss their events even though the wider network has many relays. Relay abundance does not help when routing ignores the author's map.
This personal audit takes less time than arguing about total relay counts, and it improves your actual Nostr life immediately.
Why more relays is not always better
More relays can improve resilience, but only when they add real diversity and usable capacity. A thousand abandoned test relays do not help much. A hundred private relays can be valuable for their communities but irrelevant for public publishing. Ten high-quality relays with different operators, software, policies and regions may be more useful than a huge stale list.
More relays can also create client complexity. If users add dozens of random relays, clients may slow down, duplicate events, leak queries, waste bandwidth and create confusing failure states. Good relay selection is not "add everything." It is role-based: a few public reach relays, a few trusted read relays, search relays, personal archives, local or private relays where needed.
Relay proliferation without metadata hurts discovery. If relays do not publish NIP-11, clients cannot classify them. If they do not publish limits or contact, users cannot reason about them. If they do not appear in monitoring, directories cannot track them. A relay that wants to serve the public should be legible.
There is also an energy cost. Every relay requires hosting, storage, monitoring and updates. Running many weak relays can be worse than supporting fewer serious ones. The ecosystem needs experimentation, but it also needs maintenance culture. A relay count should reward alive, operated, documented infrastructure, not only endpoint multiplication.
The better goal is not maximum relay count. The better goal is enough relays of the right kinds, run by enough independent people, visible enough for clients, funded enough to survive and diverse enough that no one endpoint becomes the network.
How to quote relay numbers honestly
If you write about Nostr relay counts, include the date. Relay numbers age quickly. Include the source. Nostr Watch, nostr.co.uk, a custom crawler, client defaults and NIP-65 crawls will produce different numbers. Include the filter. Known URLs, reachable endpoints, public write relays, NIP-11 responders and active relays are not the same dataset.
Include uncertainty. "Our crawler found 1,200 relay URLs and 430 reachable endpoints during a 24-hour window" is much stronger than "Nostr has 1,200 relays." The first sentence tells the truth. The second sentence turns a method into a myth.
Avoid using relay count as a single decentralization trophy. Pair it with operator diversity, client default concentration, NIP-65 usage, software diversity, geography, funding models, liveness and actual routing. A smaller but better-explained number beats a giant vague one.
When comparing over time, keep the method stable. If one month you count public relay lists and the next month you count NIP-66 observations, the trend may reflect method changes rather than network changes. Infrastructure measurement needs boring consistency.
The most honest phrasing is humble: "Based on this source and this method, we observed..." That sentence does not sound flashy, but it respects you and the network.
What relay counts say about resilience
Resilience is not the same as abundance. You can have many endpoints and still lack resilience if they all depend on the same operators, same software, same cloud provider, same default clients or same payment rails. You can also have a modest number of relays and still have decent resilience if the roles are diverse and clients know how to route between them.
Real resilience asks whether events can still move when a relay disappears. If your profile is on several relays, if your NIP-65 list points to live write relays, if your client uses outbox discovery, if important posts are mirrored, if search has multiple indexes and if communities have migration plans, the network can absorb failure. A raw count cannot tell you that. A role-aware count can.
Resilience also asks whether new relays can enter the map. If client defaults are hardcoded, if directories ignore small operators, if users never see relay controls and if search depends on one index, new relays exist in theory but struggle in practice. A healthy relay ecosystem is not only many relays. It is many relays that can become visible and useful.
That is why NIP-11 metadata and NIP-66 observations are so important. They lower the cost of being discovered. A relay that publishes clear metadata and appears in liveness monitoring can be evaluated by clients and users. It has a path into the map. Without that path, the relay may work perfectly for a small room and remain invisible to the wider ecosystem.
If you care about Nostr resilience, support boring infrastructure habits. Run relays with clear metadata. Publish relay lists. Use clients that respect relay lists. Keep monitors plural. Document methodology. Fund operators. Test personal recovery. This is how a network becomes resilient in the ordinary sense, not just in a protocol diagram.
How to turn counts into better products
Good products can use relay metrics quietly. A client can warn when too many write relays are down. It can suggest removing dead endpoints. It can show when a relay lacks NIP-11 metadata. It can identify which relays accepted a publish. It can label a relay as search-capable, auth-required, paid, local or archival. It can show when a user's relay list points to stale infrastructure.
The key is to make metrics actionable. "3 of 5 write relays accepted your event" is useful. "Relay X rejected this because paid writes are required" is useful. "This relay has not responded in 30 days" is useful. "Nostr has many relays" is not useful at the moment a user is trying to publish.
Products should also avoid shame-based warnings. A user may intentionally use a private relay that monitors cannot reach. A paid relay may reject public probes correctly. A local relay may be meaningful only on a local network. Do not mark every unknown relay as bad. Mark it as unknown, explain why, and let the user decide.
For builders, relay counts can guide defaults without turning defaults into invisible law. Pick defaults that are alive, policy-clear and diverse. Revisit them. Explain them. Let users replace them. Use relay metrics to improve onboarding, then give people a path out of the starter set.
For directories, the best product choice is transparency. Show categories. Show last checked. Show metadata. Show limitations. Show whether a relay is public, paid, auth-required or private when known. Let people sort by role, not only by uptime. A relay directory should make the ecosystem intelligible, not merely huge.
Sources worth opening
Open these when you want the standards and monitoring context behind relay counts.
- NIP-11: Relay information document
- NIP-65: Relay list metadata
- NIP-66: Relay discovery and liveness monitoring
- Nostr Watch: relay monitoring and network visibility
- nostr.co.uk relay list
- An empirical analysis of the Nostr social network
- strfry relay implementation
- nostr-rs-relay implementation