There are three ways to sign Nostr events.
Pasting your nsec gives the app full access to your private key. It's fast and simple, but it means you're trusting that app completely, and if the app is malicious or gets compromised, your key is gone. Browser extensions like nos2x and Alby keep your key in the extension rather than the web app. The app requests signatures and the extension signs, giving you better isolation, but your key is still in browser memory on a device connected to the internet.
Remote signing via NIP-46 means your key lives on separate hardware you control. Apps request signatures over Nostr relays, and the key never touches the app or even your daily-use device. It's the most secure option with slightly more setup. Pick based on your threat model, but for keys that matter, remote signing is worth the effort.
Nostr is a protocol, not a platform. The difference matters. A platform is controlled by a company that sets the rules, owns the data, and can change things whenever they want. Users are guests.
A protocol is a shared language. Anyone can build software that speaks it, no permission needed, no company in control. HTTP is a protocol, and the web is built on it, but no one owns HTTP. Email is a protocol, and Gmail and Outlook compete on features, but they speak the same language. Nostr is the same idea for social media. Clients compete on user experience, relays compete on reliability, but they all speak Nostr, and users can move freely between them.
A Nostr keypair is just random numbers with math applied. Generate 32 random bytes. That's your private key. Derive the public key using elliptic curve multiplication on secp256k1. Done.
The security comes from the randomness. If someone could guess your random bytes, they'd have your key, so the random source matters. Use your operating system's cryptographic random generator, not something you cooked up. Most people use a client or tool to generate keys, and under the hood, it's calling a proper random source and doing the math. Nothing secret about the algorithm. All the security is in those 32 random bytes. Keep them random. Keep them secret.
Nostr supports user-defined lists. You can create lists of people like close friends, experts, or interesting accounts. Or lists of events like bookmarks, favorites, or read later.
Lists are kind 30000 (for people) or kind 30001 (for events). They're parameterized replaceable, so you can have multiple named lists. Some clients surface lists in the UI, letting you follow a list to see its members' content or share lists with others.
Lists help manage information overload. Instead of one big follow list, create sublists for different contexts. Check your tech list when you want tech content. It's a power-user feature, but increasingly supported.
Your Nostr feed is built from events by people you follow. Clients fetch posts from the pubkeys in your follow list. They might also include replies, reposts, and reactions. The exact mix varies by client.
There's no algorithmic timeline manipulating what you see. Events appear in chronological order, or however you configure your client to sort them. Some clients offer algorithmic feeds as an option, and Primal has caching and recommendation features. But you can always return to a pure chronological feed.
You control what you see. Follow more people, see more content. Follow fewer, see less. Simple cause and effect.
Nostr supports long-form content through kind 30023 events. These are for articles, blog posts, and essays, longer than a microblog post, with a title, summary, and potentially markdown formatting.
They're parameterized replaceable events, meaning you can update your article by publishing a new version with the same identifier. The latest version wins. Some clients specialize in long-form content while others display it alongside regular posts. The event is just data; how it's presented is up to the client. Writers can publish directly to Nostr without a traditional blog platform, readers follow them like any other account, and the content lives on relays, signed and verifiable.
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.
