Quick security checklist for Nostr:
Using a remote signer for important keys? Good.
Nsec backed up in cold storage? Good.
Strong password on signer encryption? Good.
Multi-relay setup for redundancy? Good.
Auto-approve only for routine actions? Good.
Signer logs reviewed periodically? Good.
Test restore of backups done? Good.
Separate keys for different risk levels? Good.
If you're missing items, consider addressing them. Not everything applies to everyone. Match precautions to your threat model.
Revisit this list occasionally. Security is ongoing, not one-time.
Client won't connect to your signer? Here's where to look.
First, check the bunker URL. Typos break it, so make sure you copied the whole thing. Check that the relay in the URL is reachable, since both client and signer need to connect to it. If the relay is down, they can't talk. Check that your signer is running and connected to that relay by looking at the logs.
Firewall issues can block WebSocket connections, so if you're on a restrictive network, that might be the problem. Some clients have quirks, so try a different client to isolate whether the issue is client-side or signer-side. Most connection problems are URL typos, relay issues, or the signer not running. Start there.
Search on Nostr depends on relay support. Not all relays index content for search, and those that do might limit what they index. Some specialized relays focus on search, indexing more content and supporting complex queries.
Clients that offer search usually query specific search-enabled relays. Results depend on what those relays have indexed. Full-text search is expensive, so relays that offer it need more resources. Some charge for access.
For finding specific content, search is useful when available. For comprehensive discovery, browsing feeds and hashtags might work better. The ecosystem is still developing better search solutions.
Your signer is only as secure as the device it runs on. Keep the operating system updated, enable full-disk encryption, use a strong login password, and don't install random software.
If your signer runs on a dedicated device, even better. It has one job, which means a smaller attack surface and fewer ways in. Consider network segmentation too, since your signer doesn't need to be on the same network as your daily browsing. A separate VLAN or even a separate physical network adds isolation.
Physical security matters too. If someone can walk up to your server and plug in a USB stick, software security is moot. Each layer an attacker has to get through increases your safety.
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.
