threenine.io
What is a Nostr Relay?

What is a Nostr Relay?

How relays store, forward, and shape the Nostr experience

Gary WoodfineGary Woodfine Apr 11, 2026

If you're new to Nostr, one of the first terms you'll keep seeing is relay. And if you're being blunt about it, relays are one of the main things that make Nostr different from a normal social app.

There is no single Nostr server. No central company owns the network. Instead, Nostr clients publish to and read from a network of independent servers called relays.

That matters for performance, censorship resistance, privacy, reliability, and how you manage your identity.

What is a Nostr relay?

A Nostr relay is a server that accepts, stores, and forwards Nostr events.

In the basic Nostr model, users create signed events with their private key, and clients send those events to relays over WebSockets. Other clients then query or subscribe to those relays to fetch events.

The key point is this:

  • the user owns the key
  • the client provides the interface
  • the relay stores and distributes events

Nostr's base protocol is defined in NIP-01, which describes the event model and relay-client message flow. In practice, relays are part of the transport and storage layer, not the identity layer. Your identity is tied to your keypair, not to any one relay.

If you want the wider protocol context first, read What is Nostr?.

What does a relay actually do?

At a practical level, a relay does a few things:

  • accepts events published by clients
  • stores events, depending on its policy and supported event kinds
  • returns events when clients query for them
  • streams new events to subscribed clients

That means relays act a bit like a message distribution layer for the network.

But they are not all the same.

Some relays are public and open. Some are private. Some require payment. Some are focused on spam resistance. Some specialise in search or indexing. Some may aggressively prune data. Others may keep large historical datasets.

Why relays matter so much on Nostr

Relays are not just background plumbing. The relays you use directly affect:

  • whether your posts are easy to find
  • whether you see replies and mentions quickly
  • how much metadata about your usage leaks to operators
  • how resilient your account is if one relay goes away
  • how much spam or junk you see

That is why relay management matters. It is also why browser signers and clients should make relay selection easier rather than pretending it is unimportant.

Are relays part of your identity?

No. Your identity on Nostr is your keypair.

That is one of the most important design differences from a typical web platform. If a relay disappears, blocks you, or simply becomes unreliable, you do not lose your identity in the same way you would lose an account on a centralized service.

You may lose availability or discoverability on that relay, but you do not lose control of your key.

That is also why using multiple relays is common. It improves resilience and reduces dependence on any one operator.

How do clients know which relays to use?

There are a few ways clients discover or choose relays.

1. Built-in defaults

Many clients and signers ship with a seed list of relays so a new user is not dropped into an empty state.

2. User-configured relay lists

Users can add or remove preferred relays manually.

3. Relay metadata from Nostr itself

Nostr defines kind 10002 relay list metadata in NIP-65, which lets a user advertise relays they generally read from and write to.

That helps clients make better decisions, but it is not a magic source of truth. In real products, relay discovery usually works best when it combines:

  • good defaults
  • user preferences
  • cached known relays
  • relay metadata such as kind 10002

Read relays vs write relays

One useful concept in Nostr relay management is the difference between read and write relays.

  • Write relays are relays you publish your own events to
  • Read relays are relays you query for content, mentions, and activity

NIP-65 uses kind 10002 events with r tags and optional read or write markers to describe this.

This distinction matters because not every relay needs to do every job equally well.

Can anyone run a relay?

Yes. That is part of the point.

Anyone can run relay software and expose a relay on the network. That openness is part of Nostr's censorship-resistant design, but it also means relay quality varies a lot.

Some relays are well-run and reliable. Some are experimental. Some are low-quality. Some are spammy. Some disappear quickly.

So while anyone can run a relay, users and clients still need to be selective.

Relay capabilities are not identical

Nostr relays can expose metadata about themselves via NIP-11, the Relay Information Document.

That may include things like:

  • relay name and description
  • operator contact details
  • supported NIPs
  • software implementation
  • version
  • service limitations

This is useful because a client can inspect relay capabilities instead of treating every relay as interchangeable.

For example, some relays may support NIP-50 search, which adds a search filter for querying content. Others will not.

Privacy implications of relays

Relays improve decentralization, but they do not magically make everything private.

That is worth saying clearly.

A relay operator may be able to observe:

  • which IP addresses connect to the relay
  • which events are published to it
  • what queries or subscriptions a client makes
  • timing patterns around user activity

So while Nostr removes the single centralized platform model, it does not eliminate all metadata leakage.

Good relay hygiene still matters.

If privacy matters to you, think about:

  • not relying on a single relay
  • separating identities when needed
  • being selective about where you publish
  • understanding that public events are public, even on a decentralized network

If key security is your current concern, read How to Manage Keys for Nostr and What is a NIP-07 Signer?.

Security implications of relays

Relays do not hold your private key, which is good. A relay cannot simply sign on your behalf if your key is kept in a proper signer or secure key store.

But relays can still affect your experience and risk profile in other ways.

For example:

  • a malicious or badly run relay can serve poor data or incomplete results
  • a relay may disappear or stop carrying your events
  • a spam-heavy relay can degrade your experience badly
  • a relay may require payment or auth for publishing

So the security question is not just "can the relay steal my key?" The bigger question is whether the relay is trustworthy enough to be part of your publishing and discovery flow.

Why multiple relays are normal

Using multiple relays is normal on Nostr because it helps with:

  • resilience
  • reach
  • redundancy
  • portability

If one relay is down, rate-limited, or filtering aggressively, your client can still work through others.

That is one of the reasons Nostr feels different from a centralized platform. You are not meant to depend on a single host.

How relay management fits into Diogel and browser signers

A browser signer like Diogel does not replace relays. It manages keys and signing safely so websites do not get direct access to your private key.

But relay management still matters because your signer, profile tools, and Nostr clients all need sensible relay choices.

That is why relay management inside products is worth getting right. Poor defaults create noise, confusion, and weak privacy habits. Better relay selection makes the whole Nostr experience feel cleaner and safer.

If you are setting up Diogel, start here:

Conclusion

A Nostr relay is not your account. It is not your identity. It is part of the network infrastructure that helps distribute and retrieve your events.

That distinction is the whole game.

Relays give Nostr much of its resilience and openness, but they also introduce real choices around privacy, reliability, spam, and discoverability. The right way to think about them is not as magic decentralized servers, but as independent infrastructure you should choose carefully.

References