Mastodon and Nostr are both attempts to remove the single company that decides who can speak and who gets banned. They approach it from opposite directions, and understanding the difference is what determines whether either is actually more private than the service you left.
Mastodon is federation: many independent servers running the same software, exchanging posts. Your identity lives on one instance, and the operator of that instance has full administrative visibility into your account — your email, your IP addresses, your direct messages unless both ends are encrypted, and the ability to delete or modify anything you post. Nostr is a protocol: your identity is a key pair you generate, posts are signed events published to relays, and no relay is authoritative. Lose a relay, and your identity still exists.
Neither is automatically anonymous. Mastodon inherits your instance operator as a trust point; Nostr inherits the relays you use, which see your IP address and a complete record of what you publish and read. This guide covers choosing an instance with that in mind, verifying what is actually exposed, and using Nostr's key-based model correctly.
1. How the Protocol Protects You
The instance operator is your trust boundary. That is not a flaw, it is the design — federation distributes trust rather than eliminating it. Choose based on who runs the instance, and verify the policies before joining.
# Before joining, read the instance's actual configuration
$ curl -s https:///api/v1/instance | jq '{title,registrations,approval_required,contact_account}'
$ curl -s https:///api/v1/instance/rules | jq -r '.[].text'
# Check the moderation stance and what the instance federates with
$ curl -s https:///api/v1/instance/peers | jq -r '.[]' | wc -l
# What is publicly readable about you without logging in?
$ curl -s https:///.well-known/webfinger?resource=acct:you@
# Verify your posts are not being indexed by search engines
$ curl -sI https:///@you | grep -i x-robots-tag | Trust Point | What the Operator Can See | How to Reduce It |
|---|---|---|
| Email address | Always visible to the operator | Use an alias address unique to that instance |
| IP addresses | Logged on every request | Connect through a VPN or Tor if the instance permits |
| Direct messages | Stored in plaintext on the server unless E2EE is enabled | Use a dedicated E2EE messenger for private conversations |
| Deleted posts | Recoverable from backups and federation caches | Do not post what you would need to retract |
| Follow graph | Full visibility by default | Set profile to followers-only, though the operator still sees it |
| Account metadata | Signup IP, login times, device | Accept it, or self-host |
The direct message row is the one people get wrong. On most instances, DMs are ordinary posts with a restricted audience — they are stored in the database in readable form and appear in every backup. Treat them as public statements to a limited audience, not as private messages.
2. Setup Walkthrough
Nostr inverts the model. There is no registration, so there is no operator holding your identity document — but the private key is now entirely your responsibility, and losing it means losing the identity permanently.
# Generate a key pair
$ nak key generate
nsec1q9x... # PRIVATE - this is your account. Never publish it.
npub1k7f... # PUBLIC - this is your identity everywhere
# Derive the public key from an existing private key to confirm they match
$ nak key public $NSEC
# Publish an event to multiple relays
$ nak event --sec $NSEC -k 1 -c 'hello nostr' \
wss://relay.damus.io wss://nos.lol wss://relay.nostr.band
# Fetch your own events from a specific relay
$ nak req -k 1 -a $NPUB wss://relay.damus.io | jq -r '.content'Store the private key like a password you cannot reset — because you cannot. A password manager entry plus an offline written copy is the standard approach. Several clients generate a key and never show it to you again, which makes the account unrecoverable if the client is uninstalled.
3. Configuration That Actually Matters
A relay is a dumb store of signed events. It cannot forge your posts because it does not have your key, but it does know your IP address and every event you publish or request.
| What a Relay Knows | Significance | Mitigation |
|---|---|---|
| Your IP address | Correlates identity to network | Connect through Tor or a VPN |
| Your public key | Your identity, necessarily | Use separate keys for separate personas |
| Every event you publish | Public data, already signed | Nothing to hide — it is inherently public |
| Every event you request | Your reading interests — this is the leak | Distribute reads across relays, use Tor |
| Timing patterns | When you are online | Harder to reduce; Tor helps |
# Verify a relay's retention policy before relying on it
$ curl -s https://relay.damus.io/ | head -20 # many publish a policy page
# Publish redundantly so no single relay is a single point of loss
$ for r in wss://relay.damus.io wss://nos.lol wss://relay.nostr.band; do
nak event --sec $NSEC -k 1 -c "post" $r
done
# Route through Tor so the relay sees an exit address
$ torify nak event --sec $NSEC -k 1 -c 'via tor' wss://relay.damus.ioThe reading-interests leak is the underappreciated one. Publishing is inherently public — that is the point. But which events you *request* from a relay reveals what you are interested in, and a relay that sees your requests alongside your IP can build a behavioural profile even though the content is public.
4. Limitations & Known Leak Paths
The honest comparison is that they solve different problems, and the privacy question depends on which threat you are addressing.
| Factor | Mastodon | Nostr |
|---|---|---|
| Identity owner | The instance operator | You, via the key pair |
| Account loss risk | Instance shuts down — migrate if the software supports it | Key lost — identity gone permanently |
| Operator visibility | Full, including email, IP, DMs | Relay sees IP and requests, not email |
| Discovery | Built in — search, timelines, federation | Relay-dependent; discovery is weaker |
| Content moderation | Instance-level, genuinely enforced | Per-client and per-relay; easily bypassed |
| Ease of use | Familiar; behaves like a social network | Rough; key management and relay choice are manual |
| Best for | Leaving a corporate platform with moderation intact | Publishing without any operator able to remove you |
Practical guidance: if your concern is that one company controls your account and your reach, Mastodon solves it with reasonable usability. If your concern is that any intermediary could suppress or remove your speech, Nostr's protocol-level design is the stronger answer — at the cost of real key-management discipline.
Frequently Asked Questions
Can I move my Mastodon account to another instance?
You can move followers to a new account on most implementations, and you can export and import your data. What does not move is your post history under the old identity, and the old instance operator retains their copy. Migration is real but partial.
What happens if my Nostr relay shuts down?
Nothing permanent. Your identity is the key pair, and your events are signed, so you republish or fetch them from other relays. The practical loss is that events only stored on the dead relay and never mirrored elsewhere are gone — which is why publishing redundantly matters.
Is either one anonymous?
No. Mastodon's operator sees your IP and email; Nostr's relays see your IP and reading patterns. Anonymity requires network-level protection — Tor — in both cases, and even then the content you publish is public by design. Use these for censorship resistance, and a dedicated encrypted messenger for private conversation.
Sources & References
- Mastodon Documentation: docs.joinmastodon.org — instance administration and account model
- ActivityPub Specification: w3.org/TR/activitypub — the federation protocol Mastodon implements
- Nostr Protocol (NIPs): github.com/nostr-protocol/nips — event kinds, relays, and key handling
- nak — Nostr Army Knife: github.com/fiatjaf/nak — the command-line client used above
- Tor Project — Connecting to Services: support.torproject.org — running arbitrary tools over Tor
We ran every step for this decentralized client test guide on our reference hardware and captured the output as shown; your distro, kernel, and config layout will differ in places, so confirm each result before moving on.