Your Nostr profile is a kind 0 event. The content field contains JSON with your display name, about text, picture URL, banner, and other metadata. When you update your profile, you publish a new kind 0 that replaces the old one. Kind 0 is a "replaceable event," meaning only the most recent one counts. Relays should delete older versions, though not all do. Because it's just an event, updating your profile requires a signature. With a remote signer, you'd approve this separately from regular posts, and some people set their signer to require manual approval for kind 0 changes since profile updates are sensitive. Your profile is public data, and anyone can see it. Plan accordingly.

Nostr communities are like subreddits or forums. A community has a definition (kind 34550) with name, description, rules, and moderators. Posts to the community reference it with an a tag. Moderators can approve or reject posts. Approved posts appear in the community feed while rejected ones don't. This creates moderated spaces within the broader Nostr network, allowing community norms without imposing them on everyone. Community support varies by client. Some have full-featured community browsing while others ignore communities entirely. It's an opt-in layer of structure for those who want it.

Signet lets you configure what gets auto-approved. By default, you might want to approve every signing request manually, but that gets tedious for routine actions like posting and reacting. You can set policies: auto-approve kind 1 (posts) and kind 7 (reactions) from a trusted client, while requiring manual approval for kind 0 (profile changes) or kind 4 (DMs). Different keys can have different policies. A low-stakes throwaway key might auto-approve everything, while your main identity might require approval for sensitive actions. The goal is reducing friction for normal use while keeping control over what matters. Tune policies to match how you actually use each key.

Hardware security modules can protect Nostr keys. A hardware key like YubiKey or Ledger could store your nsec. Signing happens on the device, and the key never leaves protected hardware. This is higher security than a file on disk. Even if your computer is compromised, the attacker can't extract the key. Support is limited, and not all clients work with hardware keys. Integration often requires custom tooling. For most users, a remote signer like Signet provides good security without specialized hardware. For high-value keys or high-threat environments, hardware adds another layer. Match security tools to your actual risks.

Relays can rate limit you. Publish too many events too fast, the relay might reject them. Open too many subscriptions, the relay might drop some. Rate limits prevent abuse. Spammers can't flood the relay, and misbehaving clients can't consume unlimited resources. Limits vary by relay. Some are generous, some are strict. Paid relays might have higher limits. If you're building an app, handle rate limit errors gracefully. Back off and retry. Don't assume unlimited access. For normal usage, you won't hit rate limits. For automation and bots, design with limits in mind.

Most Nostr software is open source. You can read the code, verify what it does, audit it for security, fork it, and modify it. This transparency builds trust. You're not relying on a company's word. You can check yourself. Open source also means community development. Bugs get fixed by anyone who finds them, and features get added by anyone who needs them. The downside is that quality varies. Some projects are well-maintained, some are abandoned, and some are one-person efforts. But the ecosystem as a whole benefits from openness. Good ideas spread and bad ideas get exposed. Trust, but verify. With open source, you can.

Your nsec is your Nostr identity. Think of it like this: your npub is your username, anyone can see it. Your nsec is your password, except you can never change it. If someone gets your nsec, they become you. They can post as you, delete your content, impersonate you forever. There's no "reset password" button. Guard it accordingly.

Mentioning someone on Nostr uses p tags. When you reference another user in a post, your client adds a "p" tag with their pubkey. This creates a link and notifies them. The mention might appear as their display name or npub in the post content, but the p tag is what matters for notifications and indexing. Clients request events that mention your pubkey to show your notifications, and relays index p tags for this purpose. You can mention someone without them following you, and they'll see the notification if their client shows mentions. They can mute you if they don't want to. It's direct, peer-to-peer notification with no platform mediating.

Every Nostr event has the same basic structure. The id is a hash of the event content that serves as a unique identifier. The pubkey is who created it (your public key), created_at is a Unix timestamp for when it was made, kind defines what type of event it is (1 for posts, 0 for profile, etc.), tags contain metadata like mentions, references, and hashtags, content holds the actual payload (text for posts, JSON for profiles), and sig is the cryptographic signature proving you made it. The id is calculated by hashing the other fields (except sig) in a specific order, and the signature covers this hash. Change anything and the signature breaks. Simple structure, infinite possibilities. Every feature in Nostr is just a different kind with different tag conventions.

Security starts with threat modeling. Who are you protecting against? Random opportunists are stopped by basic hygiene: don't reuse passwords, don't paste nsecs into sketchy sites. Targeted attackers require more care, including separate devices, remote signing, and operational security. State-level adversaries are a different ballgame entirely with air-gapped systems and serious OpSec, but they're probably outside most people's threat model. Most Nostr users need protection against the first two, and remote signing handles a lot of it. Your keys aren't on the devices you use daily, so compromising those devices doesn't give up your identity. Know your threats and scale your defenses accordingly. Don't under-protect, but don't over-complicate either.

Bookmarks save events for later. Kind 10003 (public) or kind 30001 with d=bookmark (private) store references to events you want to keep. Public bookmarks are visible to everyone while private bookmarks are encrypted. When you bookmark a post, your client adds it to your bookmark list. You can retrieve it later without searching. Unlike likes, which are social signals, bookmarks are personal organization. Save a thread you want to read later or archive reference material. Check if your client supports bookmarks since not all do. But the protocol allows it.

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.