Quote posts embed another event in your post. You reference someone's post with commentary, and your client includes a q tag (or e tag with marker) pointing to the original. The quoted content is displayed inline. This is like a repost with added context. You're not just sharing; you're commenting on what you share. Quote posts are useful for discussion, criticism, or amplification with context. The original author sees they've been quoted. Not all clients render quotes the same way. Some show the full embedded post while some show a link. The underlying data is consistent; display varies.

Tor hides your IP address from relays. When you connect through Tor, the relay sees an exit node, not your real IP, making it harder to link your Nostr activity to your physical location or ISP identity. Some Nostr clients have built-in Tor support, while others can be configured to use a local Tor proxy. There are tradeoffs though: Tor is slower, connection reliability is lower, some relays block Tor exits, and Tor doesn't hide your Nostr pubkey, just your IP. If your threat model includes hiding your physical identity from relay operators, Tor helps. If you're just worried about client-side key security, remote signing matters more. Different tools for different threats.

Events can have expiration times. NIP-40 defines the expiration tag. Set a Unix timestamp, and relays should stop serving the event after that time. Use cases include temporary announcements, time-limited content, and ephemeral thoughts. Compliance is voluntary. Relays should respect expiration, but some might not implement it. Cached copies on clients might persist. Expiration is a soft guarantee. Better than nothing, but not a hard delete. If you use expiration, make sure your relays support NIP-40. Check their NIP-11 metadata.

The lifecycle of a NIP-46 signing request: 1. Connection: The client app and signer establish a shared secret, usually via a bunker:// URL containing the signer's pubkey and a secret token. Both parties can now encrypt messages to each other. 2. Request: When you take an action (post, like, zap), the client builds an unsigned event and wraps it in a NIP-46 request. This request is encrypted to the signer's pubkey and published as a kind 24133 event to agreed-upon relays. 3. Receipt: The signer daemon monitors those relays. It sees the encrypted event, decrypts it with the shared secret, and parses the signing request. 4. Authorization: The signer checks its policies. Is this client allowed to sign this event kind? Does it require manual approval? If manual approval is needed, it's queued for the user. 5. Signing: Once authorized, the signer signs the event with the appropriate private key, never exposing the key itself. 6. Response: The signature is wrapped in a NIP-46 response, encrypted back to the client's pubkey, and published to the relay. 7. Broadcast: The client receives the response, attaches the signature to the original event, and broadcasts the now-signed event to relays. All of this happens in milliseconds for auto-approved requests. The key never leaves the signer.

Anyone can run a Nostr relay. Popular relay software includes strfry, nostr-rs-relay, and relayer. Pick one, configure it, run it. You're now part of the network. Why run your own? Guaranteed storage for your events, control over who can post, no dependency on third parties, and educational experience. Relays need persistent storage, bandwidth, and uptime. A small relay for personal use is cheap, while a public relay serving thousands of users requires more resources. You can run a public relay, a private one, or something in between. Pay-to-post relays monetize access, community relays serve specific groups. Relays are infrastructure, and the more diverse relay operators, the more resilient the network.

nostr-tools is the standard JavaScript library for Nostr. It handles key generation, event signing, event verification, relay connections, and more. If you're building a Nostr app in JavaScript or TypeScript, you're probably using nostr-tools. Installation is simple: npm install nostr-tools. It provides primitives, not a complete client. You build on top of it. The library is well-maintained and tracks protocol changes. When new NIPs are adopted, nostr-tools usually supports them quickly. For other languages, similar libraries exist. rust-nostr for Rust, python-nostr for Python, and so on.

Entropy is randomness, and it's the foundation of your key's security. A private key needs 256 bits of entropy to be secure. That's 2^256 possibilities, more than the atoms in the observable universe. If you generate a key from a weak source, like your birthday or a simple passphrase, the actual entropy is much lower. An attacker doesn't need to try all 2^256 keys, just the ones your weak source could have produced. Good entropy comes from hardware random number generators, OS-level cryptographic sources, or properly designed tools. Bad entropy comes from "let me just pick some memorable numbers." Your key is only as strong as its randomness. Don't shortcut this.

Nostr is built on public key cryptography. Here's why that matters. You have two keys: a private key (nsec) and a public key (npub). They're mathematically linked. Your private key can create signatures that your public key can verify, but you can't work backwards from the public key to get the private key. This means anyone can verify your posts are really from you by checking the signature against your public key. But only you can create those signatures, because only you have the private key. No central authority decides who you are. No company can ban your identity. Your keypair is your identity, secured by math rather than permission.

Ephemeral events are meant to be discarded. Kind numbers 20000-29999 are ephemeral, and relays should not store them. They're passed to connected clients in real-time and then forgotten. Use cases include typing indicators, presence, and live reactions. Anything where persistence would be noise. Not all relays handle ephemeral events, and not all clients use them. It's a niche feature for specific applications. The distinction matters for understanding event kinds. Regular events are stored forever (or until deleted), while ephemeral events are fire-and-forget. Most Nostr usage doesn't involve ephemeral events, but they exist for apps that need them.

Consider using different keys for different purposes. One key for your main social identity. Another for a project account. Another for testing apps you don't fully trust yet. If a sketchy app does something malicious with your test key, your main identity stays clean. If your project needs to share posting access with collaborators, you're not handing out your personal nsec. Signet supports multiple keys for exactly this reason. Compartmentalization is good security hygiene.