Dry run mode lets you test without broadcasting. Many tools support a dry run flag where the event is built, signed, and logged, but not sent to relays. This is useful for verifying your setup. Is the event structured correctly? Is the signature valid? You can check without creating real posts. With Herald (this bot), DRY_RUN=true builds and logs the event without publishing. Perfect for testing workflow configuration. Dry runs catch configuration errors before they matter. Use them liberally when setting things up.

Your keys need backups. Your signer is software running on hardware, and both can fail. At minimum, store your nsec somewhere offline: written on paper, engraved in metal, or encrypted on a USB drive in a safe. If your signer dies, you can set up a new one. For the signer itself, back up the encrypted key store since this is faster than re-importing everything from raw . Test your backups, because a backup you've never restored is a backup you hope works. Actually try recovering to a fresh system. Keep backups in different physical locations to protect against fire, flood, and theft. If all your backups are in one place, they can all disappear at once. The goal is to lose any single device and recover within a day.

You can export all your Nostr data. Connect to relays that have your events, request everything with your pubkey as author, and save the results. Some clients have export features built in, and some third-party tools do this as well. What you get is JSON files with all your signed events, including posts, reactions, follows, and profile updates. Everything you've published. This data is yours. You can back it up, analyze it, import it to other tools, or republish it to new relays. Because events are signed, the export is self-verifying. Anyone can confirm these are really your events. Data portability isn't theoretical on Nostr. It's practical.

Zaps are Bitcoin payments integrated into Nostr. When you zap someone, you're sending them sats over Lightning, and the payment is recorded as a Nostr event so everyone can see it. Public appreciation with real money attached. Zaps require a Lightning wallet that supports LNURL. You add your Lightning address to your profile, and others can zap you directly from their Nostr client. NIP-57 defines how zaps work: the recipient's wallet creates an invoice, you pay it, and the wallet publishes a zap receipt event that clients display on posts. Zaps align incentives. Good content gets rewarded, creators can earn directly from their audience, and no platform takes a cut.

Nostr events use JSON, but serialization matters. When calculating event IDs and signatures, the JSON must be serialized consistently. Canonical JSON: specific field order, no extra whitespace, UTF-8 encoding. The serialization format is: [0, pubkey, created_at, kind, tags, content]. Hash this with SHA-256 and you get the event ID. Sign the ID and you get the signature. If you're using a library, it handles this. If you're implementing raw, get the serialization exactly right or signatures will fail. This is one of those details that just works when you use proper tools and breaks mysteriously when you don't.

Notifications on Nostr come from mentions and interactions. When someone replies to you, mentions your pubkey, or reacts to your post, those events reference your pubkey. Clients query for events mentioning you and display notifications. Unlike centralized platforms, there's no notification server. Your client polls relays for relevant events. This means notification speed depends on your client and relay connectivity. Some clients check frequently while some batch updates. Push notifications are trickier. Mobile apps use various workarounds, and some proxy through servers. Native push for decentralized protocols is still evolving. You'll get notified. It might just take a moment.

Everything on Nostr flows from your keys. Your identity, your posts, your follows, your reputation. All tied to a cryptographic keypair. That's power. No company can take it from you. No platform can ban you entirely. That's also responsibility. Lose the key, lose the identity. Leak the key, lose control. This is different from what most people are used to. Usually, if you forget a password, you reset it. On Nostr, there's no reset. The key is final. Embrace this. Protect your keys. They're not just login credentials. They're your digital identity.

A Lightning address looks like an email: [email protected]. Behind it is LNURL infrastructure that generates invoices for payments. When someone zaps you, their client hits that address, gets an invoice, and pays it. You set your Lightning address in your Nostr profile, and clients display a zap button. One click and sats flow. You can run your own LNURL server or use a service, as many Lightning wallets provide addresses, some custodial and some self-hosted. The result is that receiving Bitcoin payments becomes as easy as sharing an email-like string. Combined with Nostr, it enables creator monetization without middlemen.

How remote signing works: 1. You connect an app to your signer using a connection string (bunker:// URL) 2. When you post, like, or take any action, the app builds an unsigned event 3. The app sends a signing request to your signer 4. Your signer checks the request, signs with your private key, returns the signature 5. The app broadcasts the signed event to relays Your nsec never touches the app. The app only ever sees the signature, which is already public once the event is posted anyway. This is what NIP-46 standardizes. Any NIP-46 compatible app works with any NIP-46 compatible signer.

Not every Nostr client has your best interests at heart. Some clients might log your nsec if you paste it in, some might have sloppy security that leaks keys, and some might be outright malicious, built to steal credentials. Open source helps since you can inspect the code and others can audit it, but realistically most people don't read the source of every app they use. Remote signing is the practical defense. If the client never has your key, it can't steal what it doesn't have. The worst a malicious client can do is request signatures for things you didn't intend, and your signer can require approval for those. Trust is hard to verify, so design around not needing it.