Relay Moderation Without Pretending Relays Are Platforms
Relays can reject, rate-limit, filter, require auth and enforce local rules, but that power is different from a platform owning the whole account.
Censorship resistance is not free hosting
A relay operator is not required to host everything. They may reject spam, illegal material, abuse, oversized events, unsupported event kinds, malformed events, known scam patterns, events from blocked keys, unauthenticated writes, unpaid writes or traffic that threatens the server. That can be compatible with censorship resistance because your identity and events are not owned by one relay.
The difference is exit. If one relay rejects you, another relay can accept you. If your private key remains yours and your content is mirrored or republished elsewhere, the account is not destroyed by one operator's decision. Censorship resistance in Nostr is not the fantasy that every server must host every event. It is the practical ability to leave, republish, choose different relays, run your own infrastructure and let clients make filtering decisions closer to the user.
This distinction matters because bad language creates bad expectations. If you tell new users that Nostr means no moderation, they will be surprised by reality. Relays moderate. Clients filter. Users mute. Communities set rules. Search relays rank. Paid relays gate access. Local relays enforce membership. The healthier promise is not "no one can refuse anything." The healthier promise is "no single refusal owns your identity."
That does not make relay decisions harmless. A large relay can shape visibility. A search relay can shape discovery. A paid relay can shape who gets lower-spam access. A local relay can shape a community's memory. Exit reduces absolute control, but it does not remove power. The answer is inspectable power: metadata, policy, errors, reports, client controls and alternatives.
A relay that rejects everything uncomfortable is not neutral. A relay that accepts everything until it collapses is not useful. The useful middle is honest: what is this relay for, what does it refuse, what tools does it use, how can users know, and where can they go if the policy no longer fits?
Moderation becomes plural
In a platform, moderation often means one company's rules applied to the whole account. In Nostr, moderation can happen at several layers. A relay can reject or store events. A client can hide or rank events. A user can mute keys or lists. A community can define roles. A search relay can index selectively. A paid relay can require admission. A local relay can enforce membership. Reports can become signals for people, apps or relays. Web-of-trust systems can decide which reports or publishers matter.
That plurality is messy, but it is valuable. It means you can choose a strict client and a permissive relay, a permissive client and a strict relay, a private group with strong moderation, a public relay with minimal filtering, or a paid relay with lower spam. It also means two people may see different versions of Nostr because they chose different moderation stacks. That is not automatically a bug. It is what user-controlled infrastructure looks like.
The hard part is explaining it. A missing note may be relay rejection, client filtering, mute lists, rate limits, missing relay lists, outbox discovery failure, event deletion, unsupported event kinds, search index gaps or actual policy enforcement. If products collapse all of that into "content unavailable," users will call everything censorship or everything broken. Good UX names the layer.
Plural moderation also prevents one bad choice from becoming universal. A relay may reject a post. Another may host it. A client may hide explicit content. Another may show it. A community may ban a user. The user may still publish elsewhere. This is not utopia. It is a system where authority is distributed across infrastructure choices instead of concentrated in one company.
The design challenge is to make that distribution legible. Users need to know whether they are changing relay policy, client filters, community rules or personal mutes. Operators need to know what they are promising. Developers need to avoid pretending that one moderation layer solves all abuse.
Relays still have real power
Do not romanticize the relay layer. A popular relay can shape visibility. A paid relay can shape access. A local relay can shape community memory. A search relay can shape discovery. A relay used by many clients as a default can become a soft gatekeeper even without owning accounts. The fact that users can leave does not mean power disappears.
A relay can refuse to store an event. It can close a subscription. It can rate-limit a key. It can require NIP-42 authentication. It can allow only paid users to write. It can reject unsupported event kinds. It can reject events that are too large. It can block keys, IP ranges or clients. It can prune old events. It can choose which NIPs to support. It can return useful errors or hide behind silence.
That power is different from platform power because the relay does not own your key and cannot delete your identity everywhere. But if the relay is central to your audience, its decisions matter. If your followers mostly read from one relay and that relay rejects you, your reach changes. If a community lives on one local relay and you are removed, your local presence changes. Exit exists, but audiences and communities do not teleport automatically.
This is why relay metadata and policy matter. NIP-11 can publish contact, supported NIPs, limitations, payment requirements and software. It cannot express every moderation rule, but it can tell clients enough to stop guessing. A relay with clear metadata and policy is easier to trust, even when the policy is strict. A relay that rejects content silently forces users to invent explanations.
Power becomes healthier when it is inspectable. Who operates the relay? What does it accept? What does it reject? Does it require auth? Does it require payment? Does it publish limits? Does it respond with clear error prefixes? Does it have a contact path? Does it appear in monitoring? Does it match its own NIP-11 document?
Reports are signals, not automatic law
NIP-56 defines reporting with kind 1984 events. A report can reference a pubkey with a p tag, a note with an e tag or a blob hash with an x tag. It can include report types such as nudity, malware, profanity, illegal, spam, impersonation or other. The content may include additional explanation. That gives the network a standard way to say "this thing is objectionable" without forcing one universal reaction.
The subjective nature is explicit. Reports signal to users, apps and relays that something may be objectionable. Each agent may consume and act on them as they choose. A client might blur images when several friends report nudity. A relay admin might use reports from trusted moderators to remove illegal content. A user might ignore reports entirely. A web-of-trust system might count only reports from known keys. Reports are ingredients for moderation, not automatic judgments.
This is important because reports can be gamed. Coordinated false reports, harassment campaigns and ideological brigading are possible. NIP-56 itself warns that relays should not automatically moderate based on reports because they can be easily gamed. That does not make reports useless. It means reports need trust context. Who reported? What did they report? Does the report include evidence? Is the reporter trusted for this category? Is there a pattern?
Reports can be most useful near the user. Your friends' reports may influence your client. A community's moderators may use reports to triage a local room. A relay operator may use reports from known admins to handle spam. A public search service may use reports as one ranking signal among others. The same report event can serve several moderation layers without becoming centralized law.
Good clients should show report context carefully. A badge saying "reported" without source can be misleading. A feed option such as "hide posts reported as malware by people you follow" is clearer. A relay dashboard that shows trusted moderator reports is clearer. The report event is simple; the product decision around it is the hard part.
Groups and communities make moderation concrete
NIP-29 relay-based groups are a direct example of relay-level moderation. It defines groups that are writable only by a closed set of users, while they may be public for reading or not. Events sent to groups use an h tag with the group id. Relays can enforce membership, admin roles and moderation actions. That is not a global speech rule. It is a room rule.
NIP-29 includes join and leave requests, moderation actions, group metadata, group admins, group members and group roles. Moderation events in the 9000-9020 range can manage users, delete events, edit metadata, create invites and handle group state. Relays are expected to check whether the pubkey sending the moderation event has the right role. The relay is the enforcement point because the group belongs to a relay context.
NIP-72 moderated communities follow a related idea for Reddit-style communities. Communities can have definitions, approved moderators and post approval events. That moves moderation into a public event model where roles and approvals can be inspected. Again, the point is not that one global authority rules. The point is that community-level moderation can be represented as signed protocol data.
These NIPs matter for relay moderation because they show a pattern. Moderation can be local, role-based, signed and portable enough to inspect. A group can have admins without pretending the whole network has one admin. A community can approve posts without making every relay responsible for the community's rules. A relay can enforce a room without owning the user's identity elsewhere.
For users, this means you should ask what space you are in. A public relay is one thing. A NIP-29 group is another. A moderated community is another. A private relay is another. A client should not make all of them look like the same feed. The moderation contract changes with the room.
Abuse pressure is real
Relays face spam, harassment, illegal content, storage abuse, automated traffic, malformed requests, oversized events, repeated subscriptions, scraping, denial-of-service attempts and clients that do not respect limits. If a relay has no tools for those problems, ordinary users suffer. If it overcorrects, legitimate speech can be filtered. The honest route sits between naive openness and platform-style control.
Spam is not only annoying content. It is cost. Every accepted event may take bandwidth, storage, indexing, backup and operator attention. Every open subscription can consume resources. Every search query can become expensive. A public relay that accepts everything may become unusable for the people it meant to serve. Moderation is partly user safety and partly server survival.
Different relays need different defenses. A high-volume public relay may need rate limits, proof-of-work, write restrictions, spam filters, paid admission, web-of-trust logic and monitoring. A local relay may need membership rules. A group relay needs roles. A search relay needs indexing policy. A wallet relay needs tighter access and privacy. A personal relay may only need to reject unknown writes.
The danger is silent overreach. If a relay rejects spam with clear policy, users can understand. If it silently rejects categories of speech, users cannot tell whether the event failed, was moderated, was rate-limited or was lost. Operators should return useful errors where possible. Clients should display them. Moderation without feedback becomes paranoia fuel.
Abuse pressure also changes over time. A relay can start open and later need restrictions. A paid relay can start quiet and attract spam anyway. A local community can grow beyond informal trust. Relay policy should be revisited, not fossilized.
Good relay policy starts with metadata
A good relay policy should state what the relay is for, what it refuses, whether authentication or payment is required, what limits apply, who runs it and how to contact the operator. It should be boring, clear and visible. That clarity protects both sides. Users know what to expect, and operators are not forced to pretend that every relay is a universal public square.
NIP-11 is the first place to expose the basics. Supported NIPs, limitations, software, contact, payment, auth and policy links help clients explain the relay before a user fails. A relay can also use its website, status page, Nostr profile or documentation for more nuanced rules. The important thing is not the format. The important thing is that policy is discoverable.
Write policies in ordinary language. "Public read, paid write." "Member-only write for this community." "No illegal content or malware." "Only event kinds used by this app." "Auth required for writes." "Reports from trusted moderators may trigger removal." "Events older than 90 days may be pruned." These sentences are not glamorous, but they make the relay usable.
Limits should be visible too. Maximum event size, subscription limits, rate limits, accepted event kinds, retention windows and payment status all affect moderation outcomes. A rejected large event may look like censorship if the user never sees the size limit. A closed subscription may look hostile if the relay never exposed subscription limits. Policy and capacity are linked.
Metadata cannot carry every social nuance, but it can prevent the worst confusion. A relay with no contact, no limits, no description and silent rejection asks users to guess. Guessing is where trust dies.
Client filters are moderation too
Relays are not the only moderation layer. Clients decide what to show. A client can hide muted keys, collapse reported content, blur media, filter spam, rank trusted follows, hide unknown event kinds, show only web-of-trust content or create separate modes for public, private and local rooms. These decisions shape what users experience as much as relay storage does.
Client moderation has a different moral shape. It happens closer to the user. If you choose a client filter, you can turn it off, switch clients or change lists. That does not make client filtering neutral, especially when a dominant client hides choices. But it is less absolute than a relay refusing to store an event that no one can fetch from that endpoint.
Mute lists and label lists add another layer. NIP-51 lists can store mutes, pins, bookmarks and group lists. NIP-32 labels can attach classifications. Communities can share lists. Friends can become trust signals. The more this happens in signed open events, the more moderation becomes inspectable and portable.
Clients should explain when a filter acts. "Hidden because you muted this key." "Blurred because three people you follow reported it as nudity." "Collapsed because this relay marks the event as spam." "Unavailable because the relay rejected the event." Those are different states. If the interface hides the difference, users cannot reason about moderation.
The healthiest Nostr experience gives users layers: relay choice, client filters, personal mutes, community rules and reports. You do not need all layers at once, but you should know which layer made the decision.
Relay operators need a moderation practice
If you run a relay, moderation is not only ideology. It is operations. Decide what the relay is for. Write the policy. Publish NIP-11 metadata. Log rejection reasons carefully. Monitor abuse. Decide whether reports matter and whose reports matter. Decide how appeals or questions work. Decide retention. Decide what happens during legal pressure. Decide who can change policy.
Start narrow if you need to. A relay for a local group can restrict writes to members. A paid relay can require admission. A personal relay can accept only your own keys. A public relay can publish clear limits and refuse obvious spam. You do not need to solve all speech on the internet. You need to operate the room you actually host.
Use clear error messages. Nostr clients can understand prefixes such as blocked, rate-limited, invalid, auth-required, restricted or pow. If you reject an event, say why when safe. "blocked: event kind not accepted" is better than silence. "restricted: paid write access required" is better than a mystery failure. Clear errors reduce support load and paranoia.
Be careful with automatic moderation. Reports can be gamed. Spam classifiers can be wrong. Blocklists can drift. Web-of-trust systems can exclude outsiders. Payment can exclude legitimate users. Every automated rule needs review and override paths proportional to the relay's importance. A small private relay can be blunt. A major public relay should be more careful.
Document changes. If you add payment, say so. If you stop accepting certain event kinds, say so. If retention changes, say so. Relay moderation becomes more trustworthy when policy changes are visible before users hit them.
Your moderation routine as a user
When content disappears, do not jump to one conclusion. Check which relay should have had it. Check whether the relay is alive. Check whether your client filtered it. Check mute lists. Check whether the author updated their NIP-65 list. Check whether the relay requires auth or payment. Check whether the event kind is supported. Check whether another client sees it.
When a relay's policy bothers you, decide whether the relay is still useful for its role. You do not need every relay to match your entire worldview. A strict paid relay may be useful for low-spam publishing. A permissive public relay may be useful for broad reach. A local relay may enforce room rules. The question is whether you understand the policy and can leave when needed.
Use multiple layers. Pick relays that fit your tolerance. Pick clients that show filters honestly. Maintain personal mutes. Pay attention to reports from people you trust. Avoid giving one relay or one client the power to define your whole view. Nostr gives you tools, but you have to use them intentionally.
If you run a community, write rules before conflict. Who moderates? What gets removed? Are reports public? Can members appeal? What happens to old content? Can people export or republish? How do you handle illegal content, impersonation, spam and harassment? Good local policy prevents panic moderation.
If you publish important work, mirror it. Relay moderation is less frightening when your work lives in more than one place. A rejected event on one relay should not erase your public presence.
Keep one habit that feels almost too simple: when you add or remove a relay, write down why. "Good for my follows." "Good search." "Paid write, lower spam." "Private group." "Wallet traffic only." "Too many silent failures." A relay list without reasons becomes superstition. A relay list with reasons becomes infrastructure you can maintain.
Also separate personal comfort from network health. You may want a calm feed, and that is legitimate. You may also want a relay ecosystem where controversial speech, archival work, local communities and experimental apps can exist somewhere. You do not have to read everything for everything to remain possible. The mature Nostr posture is not "show me all content all the time." It is "let me choose my rooms without burning down other rooms."
What your client should tell you
A strong Nostr client should make moderation states visible before you need a debugger. When publishing fails, the client should show the relay, the error prefix and the plain-language meaning. "nostr.wine rejected this event because paid write access is required" teaches you something. "Failed" teaches you nothing. When an event is hidden, the client should say whether a personal mute, a client default, a report filter, a community rule or a relay response caused the hide.
That sounds like a UX detail, but it is the difference between trust and folklore. Most people do not inspect WebSocket frames. They feel the product. If the product hides moderation decisions, people invent stories. If the product names the layer, you can act. You can pay, authenticate, change relays, remove a filter, check a group rule, ask an operator or publish somewhere else.
Clients can also protect users from accidental centralization. If all your write relays share the same policy, the client can tell you. If your NIP-65 list is stale, it can nudge you. If a relay has no NIP-11 contact, no limits and no recent liveness signal, the client can mark it as unknown instead of treating it like a civic institution. If a relay rejects several event kinds you use, the client can stop routing those kinds there.
Good moderation UX should not shame users for choosing stricter spaces. It should make the trade visible. A family-friendly client can be honest about filtering. A raw client can be honest about showing more risk. A community app can be honest about room rules. The problem is not having defaults. The problem is pretending defaults are nature.
One useful client pattern is a "why am I seeing this?" and "why am I not seeing this?" view. The first can show source relay, author, follows, reports, labels and ranking reasons. The second can show missing relay, auth failure, payment gate, unsupported event kind, group rule, mute or client filter. That is how a decentralized system becomes understandable without becoming centralized.
What a relay policy can publish without becoming a legal essay
A relay policy does not need to read like a platform constitution. It can be short and practical. The relay's job is to tell you what room you are entering. A public relay might say that it accepts ordinary Nostr events, rate-limits abuse, blocks malware and illegal content, and does not guarantee permanent storage. A paid relay might say that read access is public, write access requires payment, spam reports are reviewed, and subscription status controls admission. A group relay might say that only members can write and admins can remove events from the group context.
The policy should avoid fake neutrality. "We do not moderate" is usually untrue. Even accepting only valid events is a moderation boundary. Even limiting event size is a boundary. Even rejecting unsupported event kinds is a boundary. Better to say the actual thing: "We only host the event kinds used by this app." "We reject obvious spam and malware." "We do not index adult media." "We preserve public notes but prune high-volume ephemeral traffic." These sentences let people choose.
Operators should also publish retention expectations. Moderation is not only removal. Pruning old events changes memory. A relay that keeps everything has different risk, cost and responsibility from a relay that keeps recent events or specific kinds. If you rely on a relay for archival work, retention matters as much as political policy.
Payment should be explained as access, not moral quality. A paid relay may reduce spam because abuse costs money, but paying does not make every user good. A paid relay still needs abuse handling. A free relay may be open and useful, but free does not mean infinite capacity. The honest policy names the economic model and the limits that come with it.
When policy changes, publish the change like infrastructure news. A relay that quietly switches from public writes to paid writes creates broken expectations. A relay that announces the change gives clients, users and communities time to adapt. In Nostr, exit is only humane when people can see the door before it closes.
Moderation and liveness are connected
NIP-66 liveness work is usually discussed as availability, but it also matters for moderation. A relay that is often down can look like it censored content. A relay that times out during publish can look like it rejected you. A relay that accepts writes but fails reads creates a different confusion. Before you accuse policy, check health.
The reverse is also true: moderation can affect perceived liveness. If a relay starts rejecting more writes, clients may mark it as unreliable even when the server is healthy. If a relay requires auth but the client does not handle NIP-42 well, users may think the relay is broken. If a relay restricts writes to paid users, free users may experience the relay as dead. The server is alive, but the user's route is closed.
That is why good clients should combine NIP-11 metadata, NIP-65 routing, NIP-66 liveness and relay error messages. You need all four to interpret what happened. Metadata tells you the policy. Relay lists tell you where to go. Liveness tells you whether the endpoint works. Error messages tell you why an action failed. Without that stack, moderation becomes guesswork.
For operators, monitoring should include policy outcomes, not only uptime. How many events were rejected? Why? Which event kinds? Which clients? Which users hit auth failures? Which limits are reached most often? If a relay rejects half of normal client traffic because the policy is too narrow or the metadata is unclear, users will experience that as hostility even if the rule was accidental.
For users, this means one practical thing: do not treat silence as evidence. Silence may be downtime, policy, unsupported event kinds, missing relay lists, client filtering or bad routing. Treat it as a diagnostic prompt. Check the relay. Check another client. Check another relay. Check metadata. Then decide whether the issue is technical, social or political.
Private and local moderation deserve different expectations
A private relay is allowed to be private. That sounds obvious, but people often carry public-square expectations into rooms that were never public squares. A family relay, a team relay, a wallet relay, a venue relay, a conference relay or a paid member relay can have strict write rules. The ethical question is not whether it accepts everyone. The ethical question is whether it pretends to be open while behaving closed.
Local relays need especially clear boundaries because they connect real people, places and reputations. A local relay for a meetup, hotel, club, school, conference or neighborhood cannot moderate like a global meme relay. It has safety, legal, commercial and interpersonal responsibilities. It may need admin roles, membership checks, visible rules and quick removal paths. That does not betray Nostr. It uses Nostr's plural architecture for a specific room.
The escape hatch still matters. If a local relay removes your event from that room, your key can still publish elsewhere. If a private relay does not admit you, your identity is not gone. If a group ban happens, the group state changes, not the whole network. That distinction is only useful when products make it legible. "Removed from this group" is different from "removed from Nostr."
Private moderation can become abusive when it hides behind open language. A relay that claims to be public but quietly blocks political opponents is harder to evaluate than a relay that says "members only" or "paid writes only." Clarity is not decoration. It is the user interface of trust.
You can therefore judge moderation by a simple standard: is the boundary named, is the decision local, is the exit real, and can you understand what happened? If those four answers are yes, strict moderation can coexist with an open protocol. If those answers are no, even soft moderation can become platform-like.
Failure modes to watch
The first failure is naive absolutism. If you believe every relay must accept everything, you will misunderstand server reality and abuse pressure. The second failure is platform nostalgia. If you want one authority to clean everything everywhere, you will flatten Nostr's plural design.
The third failure is silent policy. A relay rejects events without metadata, contact or useful errors. Users cannot tell whether the issue is moderation, rate limits, auth, payment, event kind support or downtime. The fourth failure is hidden client filtering. A client hides content but presents the feed as neutral.
The fifth failure is report abuse. Coordinated reports become a weapon when clients or relays act automatically without trust context. The sixth failure is unportable community moderation. A group or community becomes a closed platform if members cannot leave, fork, mirror or understand rules.
The seventh failure is monoculture. If too many clients depend on the same relay policy, one operator's decisions start to shape the network more than intended. The antidote is relay diversity, client diversity, visible policy and clean exit.
Moderation failure is rarely one big villain. It is usually an invisible layer making an uninspected decision. Inspect the layer.
The practical verdict
Relay moderation is not the end of censorship resistance. It is one of the places where censorship resistance becomes concrete. Operators can refuse to host. Users can move. Clients can filter. Reports can signal. Communities can enforce rules. Relays can specialize. The network stays healthier when those powers are visible and plural.
The strongest promise is exit with context. You should know why a relay rejected something, whether another relay can host it, whether your client filtered it, whether reports influenced it and how to change your setup. That is more useful than pretending moderation does not exist.
Good relay moderation is boring in the best way: clear metadata, clear policy, clear errors, real abuse handling, careful reports, role-based communities, visible client filters and a real path out. When those pieces exist, relays can protect their rooms without becoming platforms.
Sources worth opening
Open these when you want the standards and practical layers behind relay moderation.
- NIP-01: Basic protocol flow
- NIP-11: Relay information document
- NIP-42: Authentication of clients to relays
- NIP-56: Reporting
- NIP-29: Relay-based groups
- NIP-72: Moderated communities
- NIP-51: Lists
- NIP-32: Labeling
- Nostr Design: Relays
- Nostr.how: Relays
