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.