Your follow list is a kind 3 event. It contains p tags listing the public keys of everyone you follow, and when you follow or unfollow someone, your client publishes a new kind 3 replacing the old one. This list is public, so anyone can see who you follow. There's no private follow option in the base protocol.
Clients use your follow list to show your feed by fetching events from the pubkeys you follow. Some relays also use it to prioritize which events to store or serve. Because follows are stored in events you sign, you can easily export them. Switch clients, and your follows come with you. No need to rebuild your social graph from scratch.
Every Nostr event has a "kind" that defines what it is. Kind 0 is your profile metadata, kind 1 is a text note (the basic post), kind 3 is your follow list, kind 4 is an encrypted DM, and kind 7 is a reaction. There are dozens more covering zaps, reposts, long-form content, badges, relay lists, and more. Each NIP can define new kinds for new functionality.
When an app asks your signer to sign an event, the kind tells you what you're approving. A request to sign kind 1 is a post, while a request to sign kind 0 is changing your profile. Signers can use this for permissions: auto-approve kind 1, require manual approval for kind 0. Understanding kinds helps you understand what apps are doing with your identity.
NIP-42 lets relays authenticate clients. The relay challenges you, you sign a response with your key, and the relay now knows your pubkey and can apply policies.
Use cases include paid relays checking payment status, private relays limiting access, and rate limits based on identity. Authentication is optional, and many relays don't require it. When they do, NIP-46 compatible clients handle it transparently.
With Signet, auth challenges become signing requests. Your signer signs the auth event, proving your identity to the relay. Auth adds a layer of identity to relay connections while keeping keys secure.
Bridge bots connect Nostr to other platforms. They mirror content. A bridge might post your tweets to Nostr, or post Nostr content to Telegram, or sync across multiple protocols.
Bridges help during migration. Your audience on one platform can see you on another without switching immediately. Setting up a bridge often requires API access to both platforms. Nostr is open, but other platforms might have restrictions.
Some bridges are public services while some are self-hosted tools. Quality and reliability vary. Bridges are transitional. Eventually, you might not need them. But while building presence on Nostr, they help maintain reach.
There's no key revocation on Nostr. If your key is compromised, it's compromised forever. There's no central authority to tell "this key is no longer valid."
You can stop using the key. You can tell people it's compromised. But the attacker can still sign valid events with it. This is the tradeoff for decentralization. No authority to revoke means no authority to censor.
Mitigate by protecting keys well. Use remote signing. Keep backups secure. If compromise happens, start fresh with a new key and notify your followers through other channels.
Some clients are local-first. They store events on your device, not just on relays. You can browse your feed offline, and data syncs when you reconnect.
This has advantages: faster loading, works without internet, and your data exists locally, not just on servers you don't control. Downsides include using device storage, syncing can be complex, and different devices might have different data.
Local-first is a design philosophy, and not all clients follow it. But it aligns well with Nostr's values of your data, your device, your control. If offline access matters to you, look for clients that emphasize local storage.
Nostr has encrypted direct messages, but understand the limitations. Kind 4 DMs encrypt the content so only you and the recipient can read it, using your private keys to derive a shared secret.
But metadata isn't hidden. Everyone can see that you sent a message to someone, and when. The relay knows, anyone watching knows, and only the content is private. NIP-44 improves the encryption scheme and newer clients are adopting it, but the metadata problem remains. For truly private communication, Nostr DMs may not be enough. They're better than public posts, but they're not Signal. Use them knowing what they do and don't protect.
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.
