What is a Nostr relay? A plain English guide

Every Nostr message travels through a relay. Your client sends signed events to relays; other users' clients fetch events from relays; repeat for every post, like, follow, and DM. The relay is not a glamorous component, but it is the component that makes the network work.

This guide covers what a relay actually is, what it does and does not do, and how to think about which relays matter for your use.

TL;DR. A relay is a small server that accepts signed Nostr events over WebSocket, stores them, and forwards them to subscribers. There is no "the" Nostr relay; the network is thousands of independent relays that do not coordinate. Your client connects to several simultaneously; the union is your view of the network.

When you are ready, grab your @nostr.blog address →

What a relay does

Three jobs, all simple.

Accept events. A client opens a WebSocket connection and sends an EVENT message with a signed JSON object. The relay verifies the signature (does it match the claimed pubkey), optionally checks against policies (spam, rate limits, blocklists), and either accepts or rejects. Accepted events go into storage.

Store events. Relays use a local database (usually SQLite or PostgreSQL) indexed by event id, author pubkey, kind, and tag values. This lets them respond to subscription filters efficiently.

Serve subscriptions. A client sends a REQ message with a filter ("give me events from these authors, of these kinds, since this timestamp, limited to 100"). The relay queries its database for matching stored events, streams them, then sends EOSE (end of stored events) and keeps the subscription open. Any new event that matches the filter gets pushed to the client in real time.

That is the full relay API, with minor variants. A relay does not do anything else: no ranking, no recommendation, no moderation beyond its own policies, no cross-relay coordination.

What a relay does not do

Several things a relay could theoretically do but usually does not.

Talk to other relays. Relays are independent. They do not sync with each other. If a post is on relay A but not relay B, someone reading from only B does not see it. Replication happens because clients publish to multiple relays, not because relays mirror each other.

Enforce global rules. Each relay has its own rules. What one rejects, another accepts. There is no global policy authority.

Verify off-chain claims. A relay accepts signed events; it does not verify that "alice@example.com" in a NIP-05 field actually maps to the event's pubkey. That is the client's job.

Act as a platform. A relay is not a website with a home page, a feed, or a brand. It is a backend. Users never interact with relays directly; clients do.

Why the design is unusual

Most networks have servers that do a lot. A Mastodon instance is not just a relay; it is a full Twitter-like web application with users, profiles, timelines, moderation tools, admin dashboards. An XMPP server has users, rooms, MUC, pubsub. A matrix homeserver is a heavy piece of software.

Nostr's relay is deliberately minimal. A relay does not know who its users are (no user accounts on the relay). A relay does not own its content (the content's authenticity comes from signatures, not from who stored it). A relay does not federate (no protocol-level coordination with other relays).

This minimality is why there are so many relays. Running one is cheap because a relay does so little. A $5/month VPS can run a relay serving hundreds of active users. Compare to running a Mastodon instance, which at similar scale requires significantly more resources and maintenance.

Default relays vs custom relays

Every Nostr client ships with a default list. Common entries as of 2026:

• wss://relay.damus.io (Damus-operated, high-volume)
• wss://nos.lol (community-operated, free)
• wss://relay.primal.net (Primal-operated)
• wss://offchain.pub (community, stable)
• wss://relay.nostr.band (aggregation focus)
• wss://nostr.wine (paid, spam-filtered)

These work for most users. The first three handle most daily traffic. Replacing them is not necessary unless you have a reason. (If you signed up via nostr.blog, a curated default relay list is already configured for you; you can adjust it in settings later.)

Reasons to customize:

• Performance. A relay closer to you geographically is faster. If you are in Asia, adding an Asia-based relay speeds up reads.
• Privacy. If you do not want a specific major relay seeing your subscription patterns, use different ones.
• Topic specialization. Some relays focus on specific topics or communities. Connecting to them increases your exposure to that content.
• Spam tolerance. If you are drowning in spam, a spam-filtered paid relay might be worth the subscription.

How many relays should you use

Three or four is usually the sweet spot. More is not always better.

Too few (1-2). A single-relay outage silences your posts temporarily. Not enough redundancy.

Just right (3-6). Your posts get to enough places that outages do not matter. Read performance is good because the client can race queries across them.

Too many (10+). Each relay adds latency and data transfer. Clients must query all of them; slow ones hold up the whole feed. Battery and bandwidth go up without proportional benefit.

If in doubt, use the defaults. If specifically pursuing a reason, adjust in increments.

Relay policies matter

Every relay has unwritten or written rules about what it accepts. Most are lenient; some are strict. A few common policy types:

Write-open, read-open. Anyone can post, anyone can read. Most community relays.

Write-paid, read-open. You pay a small fee to post; anyone can read your posts. Most paid relays. Reduces spam dramatically.

Whitelist. Only approved accounts can post. Used for company or community relays.

Topic-filtered. Accepts only events matching certain criteria (hashtag, kind, length).

Geofenced. Accepts only users from specific regions. Uncommon.

Before relying on a relay, check its written policies (usually at /.well-known/nostr.json or the relay's info endpoint). If your post pattern will not match the relay's policies, writes will silently fail.

Running your own relay

Surprisingly easy. A basic setup:

1. Rent a VPS ($5/month range is fine).
2. Install a relay implementation. strfry and nostream are the two common open-source choices.
3. Open port 443 or 8080; point DNS at the server.
4. Start the relay.

Total time: under an hour for someone comfortable with Linux. No complex configuration required out of the box. Running a relay for yourself or a small community adds resilience to the network and gives you explicit control over a piece of your Nostr data.

A dedicated guide on this is in run-your-own-relay.

Relays and privacy

Each relay you connect to sees:

• Your IP address
• The filters you subscribe to (which pubkeys you read, which hashtags you watch)
• Your posts (their content, since you published them here)
• Timing of your activity

Relays do not see:

• Content of encrypted DMs (only ciphertext)
• Your private key

For users who care about minimizing relay-level metadata leakage:

• Use Tor or a VPN.
• Spread your reads across many relays so no one sees the whole picture.
• Use clients that rotate relays for different subscription types.

Most users do not need any of this. The protocol's privacy model assumes relays are semi-trusted semi-public infrastructure; it is not designed to hide your activity patterns from them.

Choosing relays: a simple rule

If you are new: keep the defaults.

If you are specifically frustrated with something (spam, speed, reliability): change only the thing that is frustrating you. Add one or two relays, or swap out the one that annoys you.

If you are advanced: curate intentionally. Pick 4-6 relays that cover your needs (geography, topics, trust level) and manage them carefully.

If you are paranoid: spread across enough independent relays that no single operator sees your full activity. Use Tor. Mix regions.

The wrong move is to add dozens of relays hoping more is better. Slow clients and wasted bandwidth are the result, not a better experience.