Relays / Research atlas

Relay Research Atlas: Software, Monitors and Source Trails

Relay research is where raw URLs become useful: software repositories, monitoring tools, directories, NIPs and operator pages.

Relays Research atlas Endpoints, policy, metadata and reliability before the next dependency.

Relays NIP-11 Sources

Relays31 min readResearch atlas

Relay Research Atlas: Software, Monitors and Source Trails

Relay research is where raw URLs become useful: software repositories, monitoring tools, directories, NIPs and operator pages.

Relay claims need receipts because the word relay hides too many jobs

Nostr relay talk gets vague fast. Someone says a relay is fast, another says it is safe, another says it is paid, another says it is for search, another says it is an outbox relay, and suddenly the same word is carrying five different promises. That is not your fault. The protocol gives relays a simple transport role, then the ecosystem builds many products and operating cultures around that role. The only way to stay sane is to keep the receipts close.

A receipt can be a NIP, a repository, a relay information document, a monitoring dashboard, an operator page, a source list, a client document or a live endpoint check. Each one answers a different question. NIP-01 tells you the basic client-relay message flow. NIP-11 tells you what a relay publicly declares about itself. NIP-42 explains authentication between client and relay. NIP-50 tells you when search is part of the claim. NIP-65 tells you how relay list metadata helps other clients discover where you write and read. NIP-66 turns relay liveness into a monitorable event stream. A software repository tells you what kind of server or framework could be running underneath. A monitoring page tells you whether an endpoint responds, not whether the operator is wise.

That distinction matters because Nostr is not a single hosted product. If a normal platform breaks, you blame the platform. In Nostr, a broken experience can come from a client default, a stale relay list, a relay that rejects your event, a search relay that never indexed the content, a paid relay that needs authentication, a local relay your friends do not publish to, or a public relay that is alive but no longer useful for your group. Research is not academic decoration. Research is how you find the layer that failed.

Good relay research starts with humility. A relay URL is not enough. A screenshot of a relay list is not enough. A GitHub star count is not enough. A famous client using an endpoint is not enough. You need a trail that lets you say: here is the standard, here is the implementation, here is the live metadata, here is the operator context, here is the monitor, here is the directory, and here is the specific job this relay is supposed to do for me.

That is also why the hub now points to an atlas instead of eight tiny research stubs. You should not have to open a 580-word placeholder to learn that strfry exists. You should get a real map: which projects are full relay servers, which are frameworks, which are libraries, which are monitors, which are directories, which are design references, which are operator surfaces, and which NIPs explain the behavior you are seeing in a client.

Software explains behavior before marketing does

When a relay advertises software, open the project. You do not need to audit every line to learn something useful. The repository can show whether the relay is a full server, a framework, a library, a specialized product, or an abandoned experiment. It can show which storage model the project expects, whether moderation hooks exist, whether NIP support is documented, whether admin tools are part of the design, and whether recent maintenance is visible.

strfry is especially important because so many public relays advertise it in NIP-11 metadata. The June 22, 2026 checks across relay.damus.io, nos.lol, relay.primal.net, relay.snort.social, nostr.mom, nostr.bitcoiner.social, offchain.pub and relay.nostr.net all reported strfry or a strfry Git URL. That does not mean those relays behave identically. Operator configuration, policy, server capacity, retention, rate limits and moderation still matter. But it tells you the software family behind a large slice of the public relay commons.

nostream is a different research object. It has been one of the visible Nostr relay server projects for people who want a full service stack rather than a tiny custom relay. When you inspect nostream, look for deployment expectations, database assumptions, admin surface, rate limiting, moderation and how the project frames production use. A full relay server is not only protocol handling; it is storage, operations, abuse control and maintenance discipline.

khatru is useful because it shifts your mental model from relay as fixed product to relay as programmable policy. A framework-style relay lets a developer build a relay for a specific job: a group, a paid room, a curated feed, a community, a bridge, a specialized event type or a local product. That flexibility is powerful, but it also means the word relay becomes even less descriptive. A khatru-based relay may be intentionally narrow. You should judge it by the product behavior it was built to express, not by generic public relay expectations.

nostr-rs-relay matters because Rust relay implementations have shaped early Nostr infrastructure experiments and self-hosting culture. When a relay implementation is written for performance, correctness or operator control, its choices can affect how people think about storage, indexing, event validation and configuration. If you self-host or evaluate a relay operator, the implementation language is less important than the operational story around it: how to deploy, how to monitor, how to update, how to back up and how to react when abuse arrives.

Nostrify belongs in the atlas as part of the developer ecosystem around Nostr infrastructure. It is not the same category as a single public relay endpoint. Read it as a toolkit and framework layer for building Nostr-aware applications and services, including relay-adjacent behavior. That matters because future relay products will not always look like classic public WebSocket servers. Some will be embedded into apps, workers, edge functions, local nodes and narrow product flows. The research question becomes: what does the toolkit make easy, and what operational responsibility does it leave to the builder?

Specialized relay software such as filter-relay or wallet-specific relay layers should be read by job. A filter relay makes policy and forwarding explicit. A wallet relay carries NWC traffic. A group relay may enforce community rules. A local relay may prioritize speed and relevance for a physical place. The implementation can tell you which constraints are built in and which are only documentation promises. When the job is specialized, generic relay advice gets weaker. You need the source trail for that exact job.

Monitors and directories help, but they do not replace judgment

Nostr Watch is valuable because it treats relay health as something you can observe rather than gossip about. Monitoring can surface whether endpoints respond, which NIPs they advertise, what metadata they publish and how their availability changes over time. That is a better starting point than relying on old screenshots or stale client defaults. If a relay is dead, slow or unresponsive, you should not need a social rumor to discover it.

Still, monitoring is not truth. A relay can be online and wrong for your use case. It can respond quickly while rejecting the events you care about. It can advertise a NIP and still disappoint you in edge cases. It can be alive today and change policy tomorrow. It can be excellent for public notes and useless for a local group. It can be reachable from the monitor's location and unreliable from yours. A monitor gives you a signal. You still have to ask what job the relay is supposed to do.

NIP-66 is important because it gives the monitoring layer a protocol-native vocabulary. Instead of every site inventing a private status format, relay liveness can be represented as Nostr events. That makes it easier for clients, directories and dashboards to share health data. It also creates a new responsibility: do not confuse the existence of a liveness event with a guarantee. You need provenance, freshness and context. Who measured it? When? From where? Against which endpoint? With which criteria?

Directories such as nostr.co.uk relay lists are useful because they expose the breadth of the ecosystem. They show that Nostr is not three famous default endpoints. They also show the danger of volume. Hundreds of relay URLs without categories can make you feel informed while giving you no decision path. A useful directory should help you separate public, paid, local, search, wallet, group, archival, experimental and offline or stale entries. A useful client should not ask you to scroll a wall of URLs and guess.

Nostr Design's relay material plays a different role. It helps translate infrastructure into product language. That matters because many relay failures are user-experience failures. A client may understand NIP-42 technically but still present an authentication challenge in a scary or confusing way. A client may support NIP-65 but hide relay list maintenance until discovery breaks. A client may let you add twenty relays but never explain what each one does. Design research keeps the human surface connected to the protocol surface.

The strongest workflow combines all of these. Use a directory to discover candidates. Use monitoring to check health. Use NIP-11 to read self-declared metadata. Use the repository to understand implementation. Use the operator page to understand policy and cost. Use your own client to test write and read behavior. Then decide whether the relay belongs in your setup. That sounds slower than copying a list, but it saves time later because you know what each URL is doing.

The standards map tells you which question to ask next

NIP-01 is the base. It defines the basic event and relay message flow that makes the rest of the conversation possible. When your client publishes an event, it sends a signed object to a relay. When it wants content, it subscribes with filters. When the relay answers, it sends matching events and status messages. That simple pattern is the reason Nostr can feel both flexible and confusing. The protocol does not dictate one home server; it lets clients and relays negotiate many paths.

NIP-11 is your first inspection tool. It is the relay's information document, usually requested with an Accept header for Nostr JSON. A good client can fetch it and show you useful language: name, description, pubkey, supported NIPs, software, version, limitations, payment and contact. When NIP-11 is missing or empty, you are not automatically forbidden from using the relay, but you should lower your confidence. Infrastructure that wants trust should introduce itself.

NIP-42 explains authentication of clients to relays. It matters because authentication in Nostr should not mean handing your private key to a server. The relay sends a challenge, the client signs a response, and the relay can decide whether that public key has access. The human risk is presentation. If a client asks you to sign something and does not explain who is asking or why, the protocol may be fine while the product feels unsafe. Good relay UX turns authentication into a legible moment.

NIP-50 marks search capability. Search is not free just because a relay stores events. Search requires indexing, query behavior and product decisions. A relay that supports search may become valuable for discovery, archives, public memory and client navigation. It also deserves separate expectations. If you expect normal public relays to behave like search engines, you will blame the wrong layer when results are thin.

NIP-65 is one of the most practical relay NIPs because it lets you publish relay list metadata. That metadata can tell other clients where you write and where you read. Without it, clients often rely on defaults, contact lists, guesses or stale caches. With it, outbox-style discovery becomes more realistic. Your relay list becomes a public hint about how to find you. Keep it current. A stale relay list is like leaving old addresses on every letter you send.

NIP-66 gives monitoring a protocol-native shape. It is part of the answer to a simple but painful problem: how do you know whether a relay is alive, responsive and telling the truth about its capabilities? NIP-66 does not eliminate the need for operator judgment, but it lets liveness and metadata observations move through the same ecosystem they describe. That is powerful when clients and directories use it carefully.

NIP-86 is mostly an operator-side concern, but it belongs in the atlas because management matters. Relays are operated systems. They need admin actions, policy changes, moderation, allow lists, block lists, payment rules, storage decisions and emergency controls. A relay market that pretends operation is invisible will always disappoint users. Standards and software around management make the operator layer easier to discuss honestly.

Software and source field notes

strfry

strfry is the implementation you will meet again and again in current public relay metadata. Its presence across many public endpoints makes it a practical baseline for the relay commons. When you see strfry in NIP-11, ask what the operator has configured around it: limits, retention, spam policy, moderation, storage, backups and supported NIPs. Software gives you a family resemblance; operation gives you the actual room.

nostream

nostream belongs to the full relay server category. Inspect it when you want to understand how a production-minded relay stack can package protocol handling, persistence, configuration and operational concerns. The research value is not only whether a particular relay uses nostream today. It is seeing how one project frames the full server problem: accepting events, storing them, serving subscriptions, controlling abuse and giving operators tools.

khatru

khatru is a framework lens. It helps you understand how developers can build relays that are intentionally narrow: a group relay, a paid relay, a curated relay, a local relay, a bridge or a product-specific relay. That matters because the next wave of relay infrastructure will not always be giant public servers. Many useful relays will be small rooms with strong policy. Read khatru when you want to think like a relay builder instead of only a relay picker.

Nostrify

Nostrify sits in the developer tooling layer around Nostr services. It is useful when you want to see how relay-aware functionality can be composed inside modern app infrastructure. That includes the possibility of relay-like behavior in workers, services and product flows that do not look like the old model of one public WebSocket server. The practical question is which pieces it gives a builder and which operating burdens still need human decisions.

nostr-rs-relay

nostr-rs-relay is part of the Rust relay lineage and early self-hosting culture. It is worth opening when you care about implementation choices, deployment, configuration and the history of relay operation. Rust does not automatically make a relay trustworthy, just as any language does not. But a visible implementation gives you something to inspect, run, compare and learn from.

Nostr Watch

Nostr Watch is the monitor and directory signal in the atlas. Use it to see endpoints as living infrastructure rather than static bookmarks. Pair it with your own checks. If a relay shows up as live, ask whether it supports the NIPs you need. If it is missing, ask whether the endpoint is truly dead or simply outside that monitor's coverage. Monitoring is strongest when you treat it as evidence, not as the final judge.

nostr.co.uk relays

nostr.co.uk relay lists show breadth. They help you discover endpoints outside your client defaults and remind you that the network is larger than the few relays everyone repeats. Use broad lists for exploration, not for copy-paste setup. Your relay list should be a chosen toolkit, not a souvenir collection from every directory you opened.

Nostr Design relays

Nostr Design is valuable because it asks how protocol behavior reaches people. A relay setting is not only a field in a config file. It is a product surface where someone decides whether to trust a room, authenticate, pay, remove a stale endpoint or understand why a feed is empty. Good design docs make the invisible infrastructure legible without making you feel foolish for not memorizing NIPs.

Read the source trail without drowning in tabs

Start with the job. If you are choosing a relay for daily posting, read NIP-11, the operator page and monitoring data. If you are debugging discovery, read NIP-65, outbox discovery material and the profile's relay hints. If you are evaluating a paid relay, read NIP-42, payment terms and metadata. If you are choosing relay software, read the repository, deployment guide, issue activity and operator stories. If you are checking a wallet path, read NWC documentation and inspect whether the relay is scoped to wallet traffic.

Then write down the answer in plain language. "This relay gives me broad public reach." "This relay is my paid write path." "This relay is for wallet messages." "This relay is a profile directory." "This relay is a local room." If you cannot finish that sentence, do not add the relay yet. The goal is not to become cautious in a boring way. The goal is to keep your network setup understandable enough that future you can repair it.

Different source types answer different questions

A NIP answers a standards question. It tells you what behavior the ecosystem has written down, which event kinds, tags, messages or flows are expected, and where clients and relays should agree. A NIP does not tell you whether a relay implements the behavior well. It also does not tell you whether a particular operator has enough money, attention or taste to run the service you need. Use NIPs for vocabulary and boundaries.

A repository answers an implementation question. It shows the code trail, license, issue history, release pattern, dependencies and architecture. It may show whether the project expects PostgreSQL, LMDB, SQLite, object storage, in-memory policy, external moderation, payment hooks or custom event handling. It may also show silence. A quiet repository is not automatically dead, but it should make you ask who maintains the deployed relay and how updates happen.

A NIP-11 response answers an operator-declared behavior question. It can say which software and version the relay advertises, which NIPs it claims, which limits it sets, and whether payment or authentication is involved. The strongest NIP-11 documents feel like a good door sign: enough information to decide whether to enter. Weak NIP-11 documents feel like a blank door in a hallway. You may still enter, but you should not pretend you were informed.

A monitoring page answers a health question. It can help you avoid dead endpoints and spot changing capability claims. It cannot tell you whether the relay's moderation matches your values, whether the operator is responsive, whether the relay will keep old events, or whether a paid service is worth the money. A monitor is excellent at answering "is something responding?" It is weaker at answering "should I depend on it?"

An operator site answers a trust and policy question. It may explain payment, contact, mission, acceptable use, retention, moderation, backups, terms, or a public-key identity. Some operator pages are careful and useful. Some are vague. Some are only landing pages. Read the tone. A relay that asks you for payment but says almost nothing about the service is making you carry too much uncertainty. A relay that clearly names its limits is doing you a favor even if you choose not to use it.

A directory answers a market question. It helps you see what exists beyond your defaults. But a directory can also flatten everything into one list. Use directories to discover, not to decide. The decision comes after you inspect metadata, role, health and source context. A list of relays is raw material. Your setup is a designed system.

A practical research loop for one relay

Take a relay URL and start with the live NIP-11 request. If it responds, write down name, software, version, supported NIPs, contact, limitations and payment hints. If it does not respond, note that too. Then search for an operator page or project page. Does the public explanation match the metadata? If the page says paid relay but the metadata says nothing about payment, ask why. If the metadata names software, open the repository. Is the software maintained? Does it match the role the relay claims?

Next, check monitoring or a directory. Has the endpoint appeared consistently? Does it show the same supported NIPs? Does it look alive from more than one signal? Then test from a client or command-line tool if you can. Publish a harmless event if appropriate, subscribe for it, and see whether it returns. If the relay requires authentication, pay attention to how the challenge appears. If it rejects the event, read the reason. A relay that says no clearly can be more trustworthy than one that fails silently.

Then categorize the relay. Public social reach, paid write path, search, directory, local room, group, wallet, archive, media, experimental, software reference or monitor. Pick one primary role. A relay can have more than one feature, but your setup needs one reason. If the reason changes, update the category or remove it.

Finally, decide the consequence. If the relay is public and useful, maybe it belongs in your read or write set. If it is paid, maybe it needs a trial and an exit date. If it is wallet-related, keep it out of social relay lists. If it is local, invite the actual group to publish there instead of only reading from it. If it is a monitor or directory, bookmark it as a research tool, not as a normal relay. The last step matters because research without a decision only creates more tabs.

When sources disagree, trust the layer closest to the claim

Relay sources often disagree. A directory may list an endpoint as alive while your client cannot connect. A relay page may claim payment behavior that the NIP-11 document does not expose. A repository may describe features that the deployed relay has not enabled. A monitor may show NIP support that has changed since the operator page was written. This is normal in a young ecosystem. The answer is not to panic. The answer is to match each source to the claim it can actually support.

If the claim is "this relay is reachable," prefer fresh monitoring and your own connection test. If the claim is "this relay supports NIP-42," prefer current NIP-11 metadata and an actual authentication flow. If the claim is "this software can build a paid relay," prefer the repository and examples. If the claim is "this operator will keep my events," prefer the operator's policy, not a directory listing. If the claim is "this relay is good for my community," prefer your own group behavior over a public ranking.

Dates help. Write them down. A relay checked on June 22, 2026 may behave differently in July. A GitHub repository updated last week carries a different maintenance signal than one untouched for years. A monitor result from today means more than a blog post from last year. You do not need a bureaucracy of citations for your personal relay list, but you do need enough date awareness that old confidence does not masquerade as current knowledge.

Also watch for copy loops. One directory repeats another, a blog post repeats the directory, a client default repeats the blog post, and suddenly everyone "knows" a relay is important without anyone opening the endpoint. The source trail should break that loop. Open the relay. Open the NIP. Open the repository. Open the operator page. Then say what you actually know.

Good client UX turns research into decisions

Most people will not manually inspect every relay. That is fine. Good clients should do some of the translation. They can fetch NIP-11 and show a readable summary. They can warn when a relay has no metadata. They can separate write relays from read relays. They can label wallet relays and search relays. They can show when a relay asks for NIP-42 authentication. They can keep NIP-65 lists from becoming stale. They can suggest removing dead endpoints instead of letting relay settings rot for years.

The design challenge is tone. A client should not scare you with protocol noise, but it should also not hide meaningful choices. "This relay asks you to authenticate" is useful. "Sign event kind 22242" may be technically accurate and emotionally useless. "This relay appears offline" is useful. "WebSocket failed" is not enough. "This relay is used for wallet messages" is useful. A generic relay URL beside social relays is underexplained.

Research pages like this one are not meant to replace client design. They set the standard for what good design should explain. If you understand the source trail, you can recognize when an app respects you. It will not make you memorize all the NIPs. It will tell you enough to make a choice.

Old research pages should become source trails, not clutter

Large archives tend to accumulate source pages. Some point to repositories, some to directories, some to NIPs, some to old guides, some to project pages that changed names. Keeping every old route as a tiny standalone page creates a bad reading experience. Deleting everything throws away useful provenance. The better compromise is to fold those routes into a stronger atlas and let the hub point to the atlas when the source is supporting evidence rather than a full editorial page.

That is the pattern here. Software and monitor icons now lead into this atlas. The old source pages can remain as historical trails or be redirected later, but the hub no longer treats them as finished editorial destinations. You get one deep explanation instead of eight shallow stops. When a source deserves a full profile, it can be expanded deliberately. When it is only evidence, it belongs in the source list.

This keeps the archive honest. A repository link is valuable. It does not automatically deserve a magazine feature. A relay operator profile may deserve a deep field note because people might depend on that service. A NIP deserves a deep explainer when it changes user behavior. A raw directory entry may only need to support a claim. Good information architecture knows the difference.

The mindset: inspectable, replaceable, humane

Relay research can sound dry until you connect it to the person using the network. You are not inspecting relays because protocols are a hobby. You are inspecting relays because your posts, follows, replies, wallet requests, local rooms and archives depend on operated places. If those places are invisible, you end up trusting them anyway, only with less language and fewer exits.

Inspectable infrastructure lets you ask better questions. Replaceable infrastructure lets you leave without burning your identity. Humane infrastructure lets normal people understand the choice without feeling stupid. That is the standard worth holding. The relay market does not need every person to become an operator. It needs clients, directories, monitors, writers and operators to make the rooms visible enough that you can move through them with confidence.

What you do with the research depends on your role

If you are choosing relays for yourself, keep the outcome small. Pick a few roles, document them in your own words and remove anything you cannot explain. You do not need the most exotic relay list in the room. You need a setup that publishes reliably, helps people find you, supports the clients you use and does not become scary when one endpoint fails.

If you are building a client, translate the research into interface decisions. Show when a relay is used for writing, reading, search, wallet messages or local rooms. Fetch metadata before treating a relay as healthy. Warn when a relay list is stale. Let people test a relay before saving it. Keep advanced details available, but lead with meaning. The best relay settings feel like a well-labeled control panel, not a drawer full of wires.

If you are operating a relay, publish enough information that people can trust you without guessing. Keep NIP-11 current. Name your software. Explain limits. Share contact. Say whether payment, authentication or restricted writes apply. Be plain about retention and moderation. If you run a local or community relay, say who the room is for. If you run a public relay, say what kind of abuse control you use. Silence makes users carry uncertainty you could remove with a few honest sentences.

If you are maintaining an archive like this one, treat raw source pages as evidence, not filler. Fold small research fragments into stronger guides. Keep old URLs from becoming dead ends. Point hub traffic toward pages that actually help someone make a decision. A link database is useful only when it becomes a map. The map is useful only when it respects the person trying to move through it.

Sources worth opening

Open these when you want the standard, implementation, monitor or operator trail behind the page. Check current repository and service state before making operational decisions.

Useful next pages

Back to Relays