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.
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.
Getting started with Signet:
First, you need a machine to run it on, whether that's a home server, a Raspberry Pi, a VPS, or anything that can run Node.js and stay online. Clone the repo, install dependencies, and start the daemon. The web UI will be available on your local network.
Add your first key through the CLI or web interface. You'll set a password that encrypts the key at rest. Don't lose this password since there's no recovery.
Connect a client by generating a bunker:// URL from Signet and pasting it into your Nostr app. The app will send a connection request, which you approve in Signet. That's it. Your posts now get signed by Signet instead of a key pasted into the app.
Check the GitHub repo for detailed setup instructions:
GitHub
GitHub - Letdown2491/signet: Signet is a self-hosted NIP-46 compliant remote signer for Nostr. This project is an extensive rewrite of nsecbunkerd. Companion app for Android available.
Signet is a self-hosted NIP-46 compliant remote signer for Nostr. This project is an extensive rewrite of nsecbunkerd. Companion app for Android av...
Cold storage keeps your nsec offline. Write it on paper. Store it in a safe. Or encrypted on a USB drive that stays in a drawer.
Cold storage is for backup, not daily use. You don't want your nsec on an internet-connected device all the time. The daily signing happens through your remote signer. But if disaster strikes, cold storage lets you recover.
Test your cold storage. Can you actually read that paper? Does that USB drive still work? Recovery you haven't tested is recovery you hope works. Treat your cold-stored nsec like you'd treat the backup of anything irreplaceable.
Building on Nostr is approachable. The protocol is simple with JSON events, WebSocket connections, and cryptographic signatures. You can understand the core in an afternoon.
Start by reading NIP-01, which is the foundation. Then explore NIPs relevant to what you want to build. Use existing libraries like nostr-tools in JavaScript or rust-nostr in Rust. Don't implement cryptography yourself unless you really know what you're doing.
Run a local relay for testing. Relay implementations like strfry or nostr-rs-relay work on localhost. Build small first with a simple client that can fetch and display events. Then add features incrementally.
Traditional 2FA doesn't quite fit Nostr. Nostr identity is a keypair, not a username/password. There's nothing to add a second factor to in the protocol itself.
But you can add layers at the signer level. Signet could require additional authentication before signing, like a PIN, biometric, or physical token. This makes your signer harder to abuse even if someone accesses your server. They'd need the second factor too.
Implementation depends on your signer setup. It's not standardized. But it's possible to add. Think of it as protecting access to your signer, not protecting the Nostr protocol itself.
Why encrypt keys on disk?
Your signer stores private keys, and if those keys are stored in plain text, anyone with access to the filesystem has your keys. A stolen laptop, a compromised backup, an attacker who gets shell access. Encryption at rest means keys are encrypted before they touch the disk, so even if someone copies the files, they get ciphertext that's useless without the password.
This protects against physical theft, backups falling into the wrong hands, and attackers who get file access but not memory access. It doesn't protect against an attacker who has full system control while the signer is running, since at that point keys are decrypted in memory, but it raises the bar significantly. Defense in depth. Every layer matters.
Connecting Signet to Primal:
Generate a bunker URL in Signet. On Primal's login screen, look for the remote signer or NIP-46 option and paste your bunker URL. Approve the connection request in Signet when it appears.
Primal will use your signer for all key operations including posting, liking, and zapping, which all go through Signet. Primal is a polished client with good NIP-46 support, so the experience should feel seamless once connected.
Remember to set up auto-approve policies in Signet if you want routine actions to happen without manual approval each time.
Quick client comparison:
Damus is iOS native with a clean, fast, well-designed interface and good NIP-46 support. Amethyst is Android native, feature-rich with active development and strong NIP-46 support. Primal covers web and mobile with a polished UI, caching infrastructure for speed, and NIP-46 support.
For web-based options, Snort is fast and minimalist, good for quick access. Nostrudel is power-user focused with lots of features, great for digging into the protocol. Coracle focuses on relay management and discovery.
This isn't exhaustive since new clients appear regularly, so check what's current. The best client is subjective, so start with one that matches your platform and priorities.