Relays, Blossom and What Actually Lives Where
Privacy gets clearer when you separate signed events from media bytes, relay policy from client display and self-hosting from magical permanence.
Relays are not neutral clouds
A relay is a server that accepts, stores and returns Nostr events according to its own policy. That policy can be simple or strict. A relay can require payment, limit event kinds, reject spam, block certain content, serve a local community, keep long archives, prune aggressively or specialize in direct messages, search, wallets, groups or public timelines.
That means relay choice is a privacy decision. A relay can observe the events you publish to it, the events you request from it, your connection timing, your IP-level network context unless you use privacy tools, and the social shape of your subscriptions. Encryption can hide payloads in some cases, but it does not erase all metadata.
The upside is that relays are replaceable. If one relay disappears or rejects your content, the protocol does not end. You can publish to another. You can use multiple relays. You can run your own relay for a community, company, venue, family archive, creator club or personal timeline. A single platform cannot be the only door.
The hard part is discovery. If your audience does not know where to look, your posts can feel missing even though the key still exists. NIP-65 relay lists help clients know where you tend to publish and read. Good clients should make relay choices visible without making every user manually tune infrastructure on day one.
Blossom stores bytes, not the social graph
Media is where many Nostr explanations become fuzzy. A photograph, video, PDF, audio file or encrypted archive is too heavy for normal relay behavior. Blossom addresses that by storing blobs on HTTP media servers while Nostr events carry the social context, hashes, metadata and discovery trail.
The name is useful: Blossom means blobs stored simply on media servers. A Blossom server is not a social relay. It does not replace event relays. It stores file bytes and returns them by hash or URL. Clients can upload media, publish an event that references the media, and other clients can fetch the bytes from the server.
This makes media portability more realistic. If the event includes a hash and clients know the author's Blossom server list, the same file can potentially be found on another server even if the first URL breaks. That is not automatic immortality. Someone has to store or mirror the file. But it gives the ecosystem a way to recover media without making one CDN the owner of every image.
For privacy, the warning is direct: a public media URL is public enough to treat carefully. Do not put private originals, member documents or sensitive files on a public media server unless they are encrypted before upload and the access pattern is intentional.
Self-hosting is a right, not a requirement for everyone
One common mistake is to explain Nostr as if every normal person must run servers. That is not how useful decentralization works. The important right is the ability to run or choose alternatives. Most people will use hosted clients, public relays, paid relays, hosted media servers and wallet services because convenience matters.
The difference from a closed platform is that hosted convenience should not be the only path. A creator with real revenue can move to a paid relay set. A community can operate its own relay. A venue can run a local relay and Blossom server. A developer can mirror media. A journalist can publish through multiple relays. A Crays node can put relay, Blossom, indexer and wallet-aware services near a real-world community.
This is closer to the original internet than to the app-store model. Not everyone runs a web server, but the web allows many hosts, domains and clients. Nostr tries to bring that replaceability to social identity and signed content.
The product challenge is making infrastructure feel calm. You should not need to understand every relay on day one. But when something breaks, the interface should be able to show where the event was published, where the media lives, which relay list is current and what can be changed.
Persistence is not the same as forever
People sometimes describe Nostr content as living forever. That is too loose. A signed event can be copied easily, and any relay that stored it may keep it. But a relay can also delete, prune, stop serving, shut down or refuse a request. A media server can vanish. A paid service can end. A local device can fail. Decentralization increases resilience; it does not suspend physics, budgets or law.
The practical privacy conclusion is two-sided. If something is public, assume it can be copied and become hard to erase. If something is important, do not assume someone else will host it forever. Public events need restraint. Important archives need redundancy.
That is why deletion requests are limited. NIP-09 lets an author publish a deletion event for past events. Responsible relays and clients can respect it. But no protocol can force every past copy to disappear from every server and screenshot. The honest product language is: you can request deletion, you can reduce availability, you can stop publishing, but public publication always carries copy risk.
For creators, this turns privacy into editorial discipline. Decide what belongs in a public note, what belongs behind paid access, what should be encrypted, what belongs on a server you control and what should never be uploaded.
Relays and Blossom both need moderation
Freedom does not remove abuse. It moves the moderation question closer to infrastructure. Relays can reject spam, illegal material, harassment patterns or file pointers they do not want to carry. Blossom servers can apply file policy, storage quotas, malware scanning, bandwidth limits, payment gates and deletion rules. Clients can mute, filter, rank and report.
This is healthier when it is explicit. A relay should be clear about what it serves. A media server should be clear about what it stores. A client should be clear about what it hides. A community should be clear about its rules. Hidden moderation creates mistrust; visible moderation lets people choose the rooms they want to enter.
A self-hosted or community relay can be more aligned with its users than a giant platform because the scope is smaller and the exit path is clearer. But smaller does not mean automatically fair. Operators still need policy, logging discipline, abuse handling, payment rules and legal awareness.
The best Nostr privacy page therefore avoids slogans. It shows where power sits: key owner, client developer, relay operator, Blossom operator, wallet provider, search index, community moderator and legal authority. Once you can see the roles, you can make better choices.
How to read a product claim about storage
When an app says it is censorship resistant, ask where events are published. When it says your media is portable, ask whether it uses hashes, Blossom, NIP-94-style metadata, mirrors or export tools. When it says you own your data, ask whether you can retrieve it without the app. When it says private, ask whether payloads are encrypted before upload and what metadata remains visible.
For Crays, the clean mental model is a layered node: Nostr relays for signed events, Blossom servers for media bytes, signers for key safety, wallets for value flow, indexes for discovery and product interfaces for normal humans. Each layer can be operated, replaced or explained. That is how privacy becomes a real architecture instead of a slogan.
Network privacy is not solved at the relay layer
A relay can see connections. Depending on setup, it may observe IP addresses, timing, subscription filters, event requests and publish behavior. If you are in a sensitive situation, the fact that a payload is signed or encrypted does not hide every network-level clue. Tor, VPNs, private relays, careful relay choice and device hygiene may matter depending on your threat model.
This is why high-risk users should not receive vague advice. A casual creator trying to preserve audience portability has different needs from a dissident publishing under pressure. The first may need multiple relays and good backups. The second may need compartmentalized identities, network privacy tools, careful device separation and minimal metadata.
Nostr can support both worlds, but the interface should not pretend they are the same. Privacy settings should be framed around risk, not only convenience.
Paid relays and local relays can improve signal
Public relays are important because they keep entry open. Paid relays and local relays are important because they can reduce spam, fund operations and align policy with a community. A paid relay can discourage throwaway abuse. A venue relay can serve people in a specific real-world room. A creator relay can prioritize member access. A company relay can preserve official history.
The danger is capture. If one paid relay becomes the default gate for visibility, the ecosystem repeats the platform problem at a different layer. The healthier pattern is plurality: public relays for access, paid relays for signal, community relays for context, personal relays for control and bridges between them.
Crays Super Nodes make sense in this frame. A venue or partner node can run useful infrastructure close to a real community while still participating in the wider Nostr network.
Sources worth opening
Open these when you want the protocol text, legal source, platform policy or implementation trail behind the article.
- NIP-01: client-relay event model
- NIP-09: deletion requests
- NIP-65: relay list metadata
- NIP-94: file metadata
- Blossom repository
- BUD-01: Blossom server requirements
- BUD-03: Blossom user server list
- BUD-11: Blossom Nostr authorization
