Relays see a lot. They see your IP address when you connect, what events you publish, and what events you request. They can correlate this to build a profile of your activity.
Using multiple relays doesn't fully solve this. You're spreading information, but each relay still sees their piece. Tor can hide your IP from relays and some clients support it, but Tor adds latency and complexity.
The fundamental tradeoff is that relays are untrusted infrastructure that you depend on. They can't forge your posts, but they can observe your behavior. Pick relays run by people or organizations you have some reason to trust, or run your own.
Nostr and ActivityPub are both decentralized, but differently. ActivityPub (Mastodon, etc.) uses servers that federate. Your account lives on one server, that server talks to others, and if your server goes down, your account is stuck.
Nostr uses keypairs and dumb relays. Your identity is your key, not your server. Relays just store and forward. Switch relays freely. No single point of failure for your account.
ActivityPub has richer features out of the box while Nostr is simpler but more resilient. Both are better than centralized platforms. Different tradeoffs. Try both if you want.
NIP-26 defines delegation: letting another key sign on your behalf. You create a delegation token, signed by your main key, saying "this other pubkey can sign kind 1 events for me until this timestamp." The delegate can then post as you, and clients verify both the post signature and the delegation token.
Use cases include bots, teams, and scheduled posting. Your main key stays secure while a less-privileged key handles day-to-day posting. Delegation has limits: you specify what kinds of events the delegate can create and for how long, and the delegate can't exceed those bounds. Not all clients support NIP-26 yet, so check before relying on it, but it's a powerful tool for managing access without sharing your actual nsec.
Replies on Nostr use e tags to reference parent events. When you reply to a post, your event includes an "e" tag pointing to the original event ID, and clients use this to build threads. Multiple reply levels create trees with the root post, then replies, then replies to replies. Tags indicate where in the tree a post belongs.
Different clients display threads differently. Some show all replies while some collapse deep threads. The data is the same, but presentation varies.
Understanding threading helps when something looks off. If a reply seems orphaned or misplaced, it might be a client rendering issue, not a data problem.
Most major Nostr clients now support NIP-46 remote signing: Damus, Amethyst, Primal, Coracle, Snort, Nostrudel, and others. The list keeps growing.
Look for "Login with bunker" or "Remote signer" or "NIP-46" in the login options. Some apps call it "nsecBunker" after the original implementation. If an app only offers "paste your nsec" with no signer option, that's a red flag for security-conscious users. Either the app hasn't implemented NIP-46 yet, or the developers don't prioritize key security. The ecosystem is moving toward remote signing as the default, and apps that don't support it are falling behind.
Global feeds show everything a relay has. Instead of filtering to people you follow, a global feed shows all kind 1 events. Everything anyone is posting.
This can be overwhelming. On a busy relay, the global feed scrolls fast with lots of noise. Global feeds are useful for discovery, letting you see what the broader network is talking about and find new people to follow. Some clients let you filter global feeds by hashtag or other criteria, which makes them more useful.
Global doesn't mean literally every post on Nostr. It means everything on the relays you're connected to. Different relays, different global views.
Nostr is automation-friendly. Events are just JSON, signing is straightforward with libraries, and relay connections are standard WebSockets. This means bots are easy to build, including scheduled posts, automated responses, data aggregation, and cross-posting. If you can script it, you can automate it on Nostr.
Signet supports automation through its CLI. Import a key, sign events programmatically, and integrate into pipelines. Remote signing is especially useful for automation. Your automation scripts request signatures from Signet, and you can set auto-approve policies for routine automated actions.
The protocol doesn't distinguish human posts from automated ones. Use this power responsibly.
📦 Signet commit
Added admin event logging to track key lock/unlock, app suspend/resume, etc. Improved pool tracking to prevent stale SSE connections from not restarting during long sleep/wake cycles. Replaced relays widget with system status widget. Added option kill switch to send daemon commands via NIP-04 and NIP-17 DMs from user-defined admin npub. Updated documentation.
a0deae7
GitHub
Added admin event logging to track key lock/unlock, app suspend/resum… · Letdown2491/signet@a0deae7
…e, etc. Improved pool tracking to prevent stale SSE connections from not restarting during long sleep/wake cycles. Replaced relays widget with s...
Nostr keys come in two formats: hex and bech32.
Hex is the raw format: 64 characters using 0-9 and a-f. This is what the cryptography actually uses. Bech32 is the human-readable format that starts with npub for public keys and nsec for private keys, and includes a checksum to catch typos. An npub1abc... is the same key as a 64-character hex string, just encoded differently.
Use bech32 when sharing or storing keys since the prefix makes it obvious what you're looking at and the checksum prevents errors. Use hex when interfacing with low-level tools or libraries that expect it. Most apps accept both, and Signet accepts both.
Spam is a challenge for Nostr. Anyone can create a keypair and anyone can post. Low barrier to entry means spammers can create endless accounts.
Defenses exist. Proof of work raises the cost of bulk posting. Paid relays filter out casual spam. Web of trust can prioritize content from people your follows follow. Clients can implement spam filters, with some hiding posts from accounts with no followers and some using reputation systems.
No solution is perfect, and spam is an ongoing arms race. But the decentralized architecture means different relays can try different approaches, and what works will spread. Your personal defense: mute aggressively and use relays with good policies.
