Clients request events from relays using filters. A filter is a JSON object specifying what you want: you can filter by event IDs, authors (pubkeys), kinds, tags, and time ranges. For example: give me all kind 1 events from this pubkey since yesterday. The relay returns matching events. Filters can be broad or narrow. Request all posts from everyone you follow, or just one specific event by ID. Relays can limit what filters they support: some don't allow unrestricted queries, some limit how far back you can search. The protocol defines the syntax; relays decide what they'll actually process. Understanding filters helps you understand what clients are doing under the hood.

Which relays should you use? Start with a mix of large public relays and smaller community ones. Damus, nos.lol, and relay.nostr.band are common defaults. Consider adding relays where people you want to follow publish. Check their relay lists. Add regional or topical relays if they fit, like Bitcoin-focused relays if that's your thing or local relays for your area. Paid relays often have better performance and less spam, worth considering for reliability. Don't add too many since each relay is a connection to maintain. Five to ten is usually enough. Review periodically. Remove relays that are slow or down, and add new ones as you discover them.

Nostr supports content warnings through tags. Add a "content-warning" tag to your event with a reason, and clients that understand this will hide the content behind a click-through. Useful for spoilers, sensitive topics, or anything that needs context before viewing. This is voluntary, and clients choose whether to respect it, though most do. It's a social convention backed by protocol. You're signaling to readers that they should have a choice before seeing this content. Good citizenship in a decentralized network. No one can force you to use content warnings, but they're a useful tool for being considerate while still posting freely.

How Signet protects your keys at rest: Your private keys are encrypted using AES-256-GCM. This is the same encryption standard used by governments and financial institutions for classified and sensitive data. "256" refers to the key size. 2^256 possible keys makes brute force computationally infeasible. The encryption key is derived from your password using PBKDF2 with 600,000 iterations. PBKDF2 is a key derivation function that intentionally slows down the process of turning a password into an encryption key. Each guess an attacker makes requires 600,000 rounds of computation. This makes dictionary attacks and brute force attempts expensive. GCM mode provides authenticated encryption. It doesn't just encrypt the data, it also detects if the ciphertext has been tampered with. You can't flip bits without detection. None of this helps if your password is "password123". Use a strong, unique password. The cryptography is only as good as the secret protecting it.

Nostr and Bluesky both aim to decentralize social media. Bluesky uses the AT Protocol, which is more complex, with DIDs, personal data servers, and algorithmic feeds. Currently more centralized in practice, though designed for federation. Nostr is simpler with keys, events, and relays. Less infrastructure, less complexity, more decentralized today. Bluesky has a polished UI and Twitter-like feel, while Nostr has more variety in clients but less polish. Both are exploring decentralization with different approaches and different tradeoffs. Some people use both. The key difference: Nostr works today without trusting any company. Bluesky's decentralization is still emerging.

Operational security is about not leaking information you don't intend to. Don't post screenshots with visible tabs or notifications, don't mention specific times that reveal your timezone, and don't share photos with metadata intact. If you want pseudonymity, maintain separation. Use different keys for different identities, don't cross-reference them, and don't log into a pseudonymous account from the same IP as your real one. Think before you post, because every piece of information narrows down who you might be, and over time small leaks add up to identification. This isn't paranoia, it's just being intentional about what you share. Your level of OpSec should match your threat model.

Anyone can propose a NIP. NIPs live in a GitHub repo. Fork it, write your proposal, and open a pull request. A good NIP clearly describes what it does, why it matters, and how to implement it. Include examples and consider edge cases. Discussion happens on the PR where people ask questions, suggest improvements, and point out problems. Be open to feedback. NIPs aren't approved by a committee. They're adopted by implementations. Write something useful, get clients and relays to support it, and your NIP becomes real. Rough consensus and running code. That's how standards grow.

NIP-46 is the Nostr protocol for remote signing. Before NIP-46, every app needed direct access to your private key. That meant pasting your nsec everywhere, trusting every client with everything. NIP-46 defines a standard way for apps to request signatures from a separate signer. The signer holds the keys. Apps just ask for signatures when they need them. Because it's a standard, you can use any NIP-46 signer with any NIP-46 compatible app. Switch signers without switching apps. Switch apps without re-entering keys. Interoperability through protocol, not platform.

Signet logs what it does: every connection attempt, every signing request, every approval or denial. This gives you an audit trail of what happened and when. Why care? If something seems wrong, logs tell the story. Did a client request something unexpected? Did a connection come from somewhere unusual? Check logs periodically and look for patterns you don't recognize. A client signing things at 3am when you were asleep might indicate a compromised client or misconfigured auto-approve. Logs are also useful for debugging connection issues. If a client can't connect, the logs show why. Visibility into your signer's activity is part of maintaining security.

Nostr has privacy limitations. Know them. Your posts are public by default, and everyone can see them. DMs hide content but metadata is visible (who talked to whom, when). Gift wrapping helps but isn't universal. Relays see your IP address. They see your pubkey. They can log all your activity. Your follow list is public. Your profile is public. Your relay list is public. If you need strong privacy, layer additional tools. Tor for IP hiding. Separate keys for separate activities. Careful operational security. Nostr is censorship-resistant, not privacy-first. Design your usage accordingly.

Stop. Don't paste your nsec into that web app. Every time you paste your private key into a website, you're trusting that site completely. With your entire Nostr identity. Forever. Use a remote signer instead. Your keys stay on hardware you control. Apps request signatures. You approve or deny. No key exposure.

Your signer encrypts keys with a password, and that password matters. If someone gets your encrypted key file, they'll try to crack the password using dictionaries, common patterns, and leaked password databases. PBKDF2 slows them down, but a weak password is still weak. Good passwords are long (16+ characters), random or high-entropy passphrases, not used anywhere else, and not based on personal info. Bad passwords include dictionary words, keyboard patterns like qwerty or 123456, personal dates and names, and anything you've used before. A password manager helps: generate something random and store it securely. Your Nostr identity is worth protecting with more than "bitcoinnostr2024".

What you can do with Signet: Multi-key management lets you store and manage multiple Nostr identities in one place, including personal accounts, project accounts, and test accounts, all accessible through the same interface. The web dashboard lets you manage keys, review connection requests, and monitor activity through your browser, running locally on your network. The Android app lets you approve signing requests from your phone, available on Zap.Store, and connects to your self-hosted Signet instance. CLI tools let you add keys and manage the daemon from the command line, allowing you to script it, automate it, and integrate it into your workflow. Signet is NIP-46 compatible and works with any client that supports the remote signer protocol, including Amethyst, Damus, Coracle, and many others. Encrypted storage means keys are encrypted at rest with AES-256-GCM, and they only exist decrypted in memory when actively needed.

Nostr is open and anyone can contribute. You can run a relay and operate infrastructure others can use, build a client and create better ways to interact with the protocol, or write a NIP to propose new features and standards. Creating content by posting interesting things helps grow the network. Helping new users by answering questions, writing guides, and making onboarding smoother is valuable. If you find something broken, report bugs to the developers. Most projects are open source on GitHub, so you can contribute code directly. There's no company to apply to and no gatekeepers. If you build something useful, people will use it.

Bots are first-class citizens on Nostr. A bot is just another keypair posting events. There's no special registration and no API rate limits in the protocol (individual relays might limit). Good bots add value with price feeds, news aggregators, bridge bots that cross-post, and utility bots that provide services. Bad bots spam, and relays and users block them. If you run a bot, disclose it in the profile. Let people know they're interacting with automation and follow relay rules about automated posting. Bot development is a good way to learn Nostr development with a simple use case and clear inputs and outputs.

REQ and EVENT are the core WebSocket messages. REQ requests events from a relay. You send a subscription ID and filters, and the relay responds with matching events. EVENT sends an event to a relay, for publishing your own events or when relays push events matching your subscription. CLOSE ends a subscription. EOSE signals "end of stored events" and the start of live streaming. OK acknowledges event acceptance (or rejection). That's basically it. The protocol is simple. Open a WebSocket, send these messages, handle responses. Everything else is built on this foundation.

Every Nostr event has a unique ID. Here's how it's calculated. Take the event fields (pubkey, created_at, kind, tags, content), serialize them as a JSON array in a specific order, and hash that with SHA-256. The result is the event ID: 32 bytes, usually displayed as 64 hex characters. This means the ID is deterministic. Given the same event data, anyone calculates the same ID. It also means you can't change anything about an event without changing its ID. The signature signs this ID, so when you verify a signature, you're verifying that the claimed author signed this exact content, down to the byte. Tamper-evident by design.

Nostr can use proof of work to fight spam. NIP-13 defines how: an event includes a "nonce" tag with a target difficulty, and the event ID must have a certain number of leading zero bits, which requires computational effort to achieve. Relays can require proof of work for posting. The harder the work, the more expensive it is to spam. Legitimate users do the work once; spammers have to do it for every message. This isn't mandatory and many relays don't require it, but it's a tool in the toolkit for relay operators dealing with spam problems. The difficulty is adjustable, easy enough for normal use, hard enough to deter bulk abuse. Economics of computation as defense.

Bunker URLs are how apps connect to remote signers. They look like this: bunker://pubkey?relay=wss://relay.example&secret=token The pubkey identifies your signer. The relay is where the app and signer will exchange encrypted messages. The secret is a one-time token that proves you authorized this connection. When you paste a bunker URL into an app, the app uses this information to send a connection request to your signer. You approve it, and now the app can request signatures through that relay. The URL itself isn't sensitive after initial connection. The secret is single-use. But treat it like a password until you've completed the handshake.

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.