threenine.io
Nostr Relays, Privacy, and Security

Nostr Relays, Privacy, and Security

What relays can see, what they cannot, and how to reduce avoidable risk

Gary WoodfineGary Woodfine Apr 11, 2026

A lot of people arrive on Nostr with a simple mental model:

  • decentralized means private
  • relays are neutral pipes
  • if there is no central platform, the risk mostly disappears

That is too simplistic.

Nostr's architecture is a real improvement over centralized social platforms in many ways, but it does not remove privacy and security trade-offs. It just moves them around.

If you use Nostr seriously, you need to understand what relays can see, what they cannot do, and where the real risks still live.

First: a relay is not your key store

This is the good news.

A relay is not supposed to hold your private key. If you are using a proper signer, wallet, or secure key manager, your private key stays on your device or in your secure key environment.

That is the entire point of tools like NIP-07 signers.

So a relay is not the same kind of risk as pasting your nsec into random websites.

If you need that background first, read:

What a relay can usually see

A relay operator may be able to observe at least some of the following:

  • the IP address connecting to the relay
  • when a client connects and disconnects
  • what public events are published to that relay
  • what subscriptions or filters a client requests
  • what accounts, event ids, or tags appear in those requests
  • timing patterns that may reveal usage habits

That does not mean every relay operator is hostile. It means the infrastructure can observe metadata, and users should be honest about that.

What a relay usually cannot do on its own

If your key is managed correctly, a relay should not be able to:

  • sign events as you
  • recover your private key from public events
  • directly impersonate you without some separate compromise

That distinction matters.

Relay risk is often more about:

  • metadata exposure
  • censorship or filtering
  • availability
  • spam and junk data quality
  • poor operational behavior

than about direct key theft.

Public events are still public

This should be obvious, but it gets blurred in decentralized conversations.

If you publish a public event to public relays, then the content is public. Spreading it across independent infrastructure does not make it private.

Nostr can improve censorship resistance and portability, but that is not the same as private-by-default communication.

So a practical privacy mindset starts with not lying to yourself about what you are publishing.

Relay diversity helps, but it is not a privacy silver bullet

Using multiple relays is usually better than relying on one. It helps with:

  • resilience
  • reach
  • reducing dependence on a single operator
  • reducing the blast radius of one bad relay

But it does not eliminate observation.

If you publish the same public event to several relays, you have increased distribution and resilience, not secrecy.

So relay diversity is mostly about availability and robustness first, and privacy posture second.

Relay metadata helps, but should not be trusted blindly

NIP-11 defines the Relay Information Document. Relays may expose information such as:

  • name
  • description
  • contact details
  • supported NIPs
  • software
  • version
  • terms of service

That is useful. It gives clients and users more context.

But it is still self-reported metadata. It helps with decision-making, not certainty.

A client should use relay metadata intelligently, not treat it as proof of quality or integrity.

Search-capable relays may expose more about how you query

NIP-50 defines a search capability where clients can send a human-readable search filter to a relay.

That is useful for discovery and retrieval, but it also means the relay may learn more about what you are actively looking for.

Again, this is not automatically bad. It is just part of the privacy trade-off.

The more powerful the relay feature set, the more important it is to be honest about what information your client is sending upstream.

Read relays and write relays are a useful security boundary

NIP-65 defines relay list metadata through kind 10002, allowing users to advertise relays for reading and writing.

That distinction is useful because not every relay needs the same level of trust for every role.

For example:

  • a relay you rely on for publishing your own events should be dependable
  • a relay you use for mentions or discovery should be relevant and useful
  • a relay you only test against should probably not become a permanent default

That mindset helps keep relay setup intentional rather than chaotic.

The biggest privacy and security mistakes people make

1. Confusing decentralization with anonymity

Nostr is decentralized. That does not automatically mean anonymous.

2. Publishing through random relays without thinking

If you add every relay you find, you increase noise and potentially increase metadata spread to operators you have never evaluated.

3. Ignoring key hygiene because the protocol feels safer than Web2

Nostr removes some central points of failure, but bad key handling still destroys you.

4. Treating all relays as equal

They are not equal in quality, policy, feature support, or operator trust.

A safer practical approach to relay usage

If you want a more disciplined setup, do this:

  • use a proper signer instead of pasting private keys into sites
  • keep your relay list small and intentional
  • prefer relays with useful metadata and a clear purpose
  • do not rely on one relay alone
  • avoid stuffing your setup with random dead or junk relays
  • treat public content as public
  • separate identities when your use cases genuinely differ

Where Diogel fits into this

Diogel helps on the key side of the equation. It keeps the private key in the extension and handles signing without handing your key to the website.

That is a real security improvement.

But signer security does not make relay choices irrelevant. You still need a sensible relay setup if you want:

  • a cleaner reading experience
  • better publishing reliability
  • fewer junk relays in your workflow
  • a more honest privacy posture

That is why relay management inside signer and client tooling matters. It directly shapes the security and privacy quality of the user experience.

Conclusion

Nostr relays improve decentralization, resilience, and user control. But they do not remove the need to think.

A relay can still observe metadata. A bad relay can still degrade your experience. A noisy relay list can still create confusion and risk. And none of that is fixed by pretending decentralized systems are magically private.

The practical answer is simple:

  • protect your keys properly
  • choose relays deliberately
  • understand what public really means
  • use better defaults instead of random ones

References

How to self-host your NIP-05 identity

Learn how NIP-05 maps a human-readable identifier like name@domain.com to your Nostr public key using a nostr.json file on your own domain.

What is a NIP-07 signer?

Learn what a NIP-07 signer is, how browser extensions expose the window.nostr API, and why this model is safer than pasting your Nostr private key into websites.