Never rely on a single relay. If your only relay goes offline, you disappear from Nostr. If it gets hacked, your event history could be lost. If the operator decides to ban you, you're cut off.
Using multiple relays means redundancy. Your events exist in multiple places, readers can find you through any of them, and there's no single point of failure. Five to ten relays is a reasonable number, with a mix of large public relays and smaller community ones, and maybe a paid relay for reliability. More relays means more bandwidth and slightly slower posting, but the resilience is worth it. Don't put all your eggs in one basket.
Nostr started in 2020, created by fiatjaf. The idea was simple: what if social media used public key cryptography instead of usernames and passwords? What if the network was a protocol anyone could build on?
It gained traction slowly at first, with a few developers building clients and a few relays coming online. The community was small but dedicated. Adoption accelerated in late 2022 and 2023 as high-profile users joined, client development picked up, and the protocol matured through real-world usage. Nostr isn't finished. NIPs are still being proposed, clients are still improving, and the ecosystem is young and evolving. But the foundation is solid: simple protocol, strong cryptography, decentralized architecture. The rest is building.
Nostr makes censorship expensive and inconvenient. There's no central server to shut down, no company to pressure, and no database to seize. Just a protocol that anyone can implement.
To silence someone on Nostr, you'd need to convince every relay to refuse their events. Given that anyone can run a relay, that's practically impossible. Individual relays can moderate and individual clients can filter, but network-wide censorship requires controlling the entire network, which is decentralized by design. This doesn't mean anything goes. Communities can set norms and tools exist for muting and blocking, but the choice is distributed, not centralized. Censorship resistance isn't about enabling bad content. It's about ensuring no single entity controls the discourse.
Relay reliability varies widely. Some relays are run professionally with high uptime, while some are hobby projects that go down unexpectedly.
Signs of a reliable relay include consistent uptime, fast responses, active maintenance, and clear policies. Red flags include frequent downtime, slow connections, no contact info, and an abandoned feel. Paid relays tend to be more reliable since the payment funds infrastructure and filters out casual abuse.
Check relay status tools to see what's up, what's down, and what's historically stable. For your critical relays (the ones in your bunker URL, for example), reliability matters more. Choose carefully.
📦 Signet commit
Migrated to React 19/Vite 7 and upgrade all dependencies to the latest versions. Additionally, fixed some outstanding bugs, fixed a couple of security vulnerabilities, and implemented some performance improvements across signet-daemon, signet-ui, and signet-android
c6f6fa0
GitHub
Migrated to React 19/Vite 7 and upgrade all dependencies to the lates… · Letdown2491/signet@c6f6fa0
…t versions. Additionally, fixed some outstanding bugs, fixed a couple of security vulnerabilities, and implemented some performance improvements...
Every Nostr event has a created_at timestamp. It's a Unix timestamp in seconds, and when you publish, your client sets this to roughly the current time.
Relays can reject events with timestamps too far in the future, and some reject events too far in the past. This prevents backdating or future-dating abuse. But timestamps are self-reported, and a sophisticated actor can manipulate them within whatever bounds relays accept. Don't rely on timestamps for strong guarantees about when something was actually created. For ordering events, timestamps are usually good enough. For proving exact timing, you'd need external verification. Nostr timestamps are useful, not authoritative.
The gossip model is how Nostr spreads events efficiently. You don't need to be connected to every relay. Events propagate. Someone posts to their relays, those relays send to connected clients, and clients might republish to their relays.
This means your content spreads beyond where you directly post. Coverage increases organically. But it's not guaranteed. If you post to an isolated relay that nobody else uses, the event might stay there.
Publishing to multiple well-connected relays gives events the best chance to propagate. The network does the rest.
The outbox model is how clients find where people publish. When you follow someone, their relay list (NIP-65) tells you where they write, and your client connects to those relays to fetch their content. When you publish, your relay list tells others where to find you.
This is more efficient than connecting to every possible relay. You only connect to relays where relevant people actually post. Clients that implement the outbox model handle this automatically. You follow someone, the client finds their relays, and you see their posts.
It's a key piece of making Nostr scale. Follow anyone, discover their relays, stay connected.
Relays see a lot. They see your IP address when you connect, what events you publish, and what events you request. They can correlate this to build a profile of your activity.
Using multiple relays doesn't fully solve this. You're spreading information, but each relay still sees their piece. Tor can hide your IP from relays and some clients support it, but Tor adds latency and complexity.
The fundamental tradeoff is that relays are untrusted infrastructure that you depend on. They can't forge your posts, but they can observe your behavior. Pick relays run by people or organizations you have some reason to trust, or run your own.
Nostr and ActivityPub are both decentralized, but differently. ActivityPub (Mastodon, etc.) uses servers that federate. Your account lives on one server, that server talks to others, and if your server goes down, your account is stuck.
Nostr uses keypairs and dumb relays. Your identity is your key, not your server. Relays just store and forward. Switch relays freely. No single point of failure for your account.
ActivityPub has richer features out of the box while Nostr is simpler but more resilient. Both are better than centralized platforms. Different tradeoffs. Try both if you want.
NIP-26 defines delegation: letting another key sign on your behalf. You create a delegation token, signed by your main key, saying "this other pubkey can sign kind 1 events for me until this timestamp." The delegate can then post as you, and clients verify both the post signature and the delegation token.
Use cases include bots, teams, and scheduled posting. Your main key stays secure while a less-privileged key handles day-to-day posting. Delegation has limits: you specify what kinds of events the delegate can create and for how long, and the delegate can't exceed those bounds. Not all clients support NIP-26 yet, so check before relying on it, but it's a powerful tool for managing access without sharing your actual nsec.
Replies on Nostr use e tags to reference parent events. When you reply to a post, your event includes an "e" tag pointing to the original event ID, and clients use this to build threads. Multiple reply levels create trees with the root post, then replies, then replies to replies. Tags indicate where in the tree a post belongs.
Different clients display threads differently. Some show all replies while some collapse deep threads. The data is the same, but presentation varies.
Understanding threading helps when something looks off. If a reply seems orphaned or misplaced, it might be a client rendering issue, not a data problem.
Most major Nostr clients now support NIP-46 remote signing: Damus, Amethyst, Primal, Coracle, Snort, Nostrudel, and others. The list keeps growing.
Look for "Login with bunker" or "Remote signer" or "NIP-46" in the login options. Some apps call it "nsecBunker" after the original implementation. If an app only offers "paste your nsec" with no signer option, that's a red flag for security-conscious users. Either the app hasn't implemented NIP-46 yet, or the developers don't prioritize key security. The ecosystem is moving toward remote signing as the default, and apps that don't support it are falling behind.
Global feeds show everything a relay has. Instead of filtering to people you follow, a global feed shows all kind 1 events. Everything anyone is posting.
This can be overwhelming. On a busy relay, the global feed scrolls fast with lots of noise. Global feeds are useful for discovery, letting you see what the broader network is talking about and find new people to follow. Some clients let you filter global feeds by hashtag or other criteria, which makes them more useful.
Global doesn't mean literally every post on Nostr. It means everything on the relays you're connected to. Different relays, different global views.
