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.