Privacy on Nostr: Complete Guide

Introduction

Nostr offers powerful censorship resistance, but privacy requires active effort. The protocol is public by design, and many privacy considerations differ fundamentally from traditional platforms.

This guide explains what’s private, what’s not, and how to maximize your privacy on Nostr depending on your threat model.

Understanding Nostr’s Privacy Model

What Is Public by Default

On Nostr, assume everything is public unless explicitly encrypted:

Completely Public:

All posts (notes, long-form content)
Your public key (npub)
Your profile information (name, bio, picture)
Who you follow
Who follows you
Your relays (often visible)
Post timestamps
Reactions (likes, reposts)
Zap amounts and recipients

This is by design: Nostr is an open protocol optimized for censorship resistance, not privacy.

What Can Be Private

Potentially Private (with effort and trade-offs):

Your real identity (use pseudonyms)
Your IP address (use VPN/Tor)
Your location (don’t reveal in content/metadata)
Direct messages (encrypted via NIP-04, though imperfect)
Your device/browser fingerprint (limited protection available)

Privacy vs. Censorship Resistance

The Inherent Tension:

Nostr maximizes censorship resistance by making content:

Publicly accessible
Widely distributed
Permanently persistent (on relays)
Independently verifiable

This conflicts with privacy, which often requires:

Limited data distribution
Controlled access
Deletion capabilities
Anonymity

You must choose your priority and accept trade-offs.

Threat Model Assessment

Before implementing privacy measures, understand your threat model.

Who Are You Protecting Against?

Casual Observers:

Threat: People you know finding your account
Protection Level: Pseudonyms, separate identity
Difficulty: Low

Commercial Tracking:

Threat: Advertising networks, data brokers
Protection Level: VPN, tracker blocking
Difficulty: Medium

Targeted Surveillance:

Threat: Stalkers, abusive individuals
Protection Level: Operational security, multiple identities
Difficulty: High

State-Level Actors:

Threat: Government surveillance, legal compulsion
Protection Level: Tor, extreme operational security
Difficulty: Very High

Choose your threat model realistically. Perfect anonymity is extremely difficult; practical privacy is achievable.

Identity and Pseudonymity

Creating a Pseudonymous Identity

Basic Pseudonymity:

Generate New Keys:
- Use a fresh identity unconnected to your real name
- Generate offline if paranoid (air-gapped computer)
- Never reuse keys from another context
Choose a Pseudonym:
- Not connected to real name or other online identities
- Avoid personally identifying information
- Consider disposable vs. long-term pseudonym
Profile Information:
- Generic avatar (no photos of yourself)
- Minimal bio (no identifying details)
- No location information
- No website linking to real identity
Content Discipline:
- Don’t reveal identifying details in posts
- Avoid photos/videos containing metadata
- Be aware of writing style/vocabulary patterns
- Don’t reference real-world activities uniquely

Identity Separation

Compartmentalization Strategy:

Identity 1: Public/Verified:

Real name or business identity
NIP-05 verified
Public presence
Connected to website/social media
No expectation of privacy

Identity 2: Pseudonymous:

Unconnected to real identity
Privacy-conscious practices
Separate client/device usage
Different relay selection
Moderate privacy

Identity 3: Anonymous/High-Security:

Tor-only access
Maximum operational security
Temporary/disposable
No identifying content ever
Maximum privacy

Never cross-contaminate identities. One slip can link them permanently.

Metadata and Information Leakage

Metadata often reveals more than you think.

What Metadata Reveals

Timing Patterns:

When you post reveals timezone
Regular posting schedule reveals routine
Active hours reveal location/lifestyle

Language and Style:

Language reveals nationality/region
Vocabulary suggests education level
Writing style can be fingerprinted
Consistent style links pseudonymous accounts

Social Graph:

Who you follow reveals interests/community
Who follows you reveals your audience
Mutual connections can identify you
Network analysis can de-anonymize

Relay Choices:

Relays reveal geographic region
Specialized relays reveal interests (e.g., Bitcoin relay = Bitcoin interest)
Relay IP addresses visible to network observers

Client Information:

Some clients include user agent in events
Client choice reveals technical sophistication
Mobile vs. desktop reveals usage pattern

Minimizing Metadata Leakage

Timing:

Post at random/varied times
Don’t establish predictable patterns
Use scheduling (if client supports) to randomize timing
Avoid posting during personally identifying times

Content:

Remove EXIF data from images before posting
Don’t reference local events/news
Avoid unique turn of phrase
Consider using different writing styles for different identities

Social Graph:

Follow more broadly (not just friends)
Don’t follow same people across identities
Be aware that followers’ follows are public

Relay Selection:

Use geographically diverse relays
Mix general and specialized relays
Change relay selection periodically
Understand your relay operators

Network-Level Privacy

Your IP address is visible to relays and network observers.

IP Address Exposure

What Relays See:

Your IP address when you connect
Connection duration
How often you connect
Which events you publish/request

Risks:

IP reveals geographic location (city-level)
ISP knows you’re using Nostr
Relay operators can log IP addresses
Malicious relays can correlate activity

Protection Options (in order of effectiveness):

Tor (maximum anonymity)
VPN (good privacy, practical)
Public WiFi (minimal protection, inconvenient)
No protection (assume IP is public)

Using VPNs with Nostr

What VPNs Provide:

Hide your real IP from relays
Prevent ISP from seeing Nostr traffic details
Choose apparent location
Bypass geographic restrictions

What VPNs Don’t Provide:

Anonymity (VPN provider knows your real IP)
Protection from VPN provider
Security from malicious relays (still need HTTPS/WSS)
Protection from content/metadata leakage

Choosing a VPN:

Recommended Characteristics:

No-logs policy (verified/audited)
Not based in surveillance-friendly jurisdiction
Accepts cryptocurrency payment
Good performance (WebSocket compatible)
Kill switch (prevents IP leakage)

Recommended Services:

Mullvad: Privacy-focused, accepts cryptocurrency, audited
IVPN: No-logs, privacy-focused, audited
ProtonVPN: Reputable, Swiss-based, free tier available

Configuration:

Enable kill switch (blocks traffic if VPN disconnects)
Enable DNS leak protection
Connect before opening Nostr client
Verify IP is hidden (check IP address websites)

Using Tor with Nostr

Tor provides maximum network-level anonymity.

What Tor Provides:

Complete IP anonymity (relays see Tor exit node IP)
Metadata protection (ISP can’t see what you’re accessing)
Bypass censorship
Multi-layered routing

Challenges:

Slower connection speeds
Some relays block Tor exit nodes
Requires compatible clients
More complex setup

How to Use Tor with Nostr:

Option 1: Tor Browser + Web Client:

Download Tor Browser
Access Nostr web client (Snort, Iris, Nostrudel)
Use with browser extension (nos2x)
All traffic routed through Tor

Pros: Simple, built-in Tor protection Cons: Slower, fewer relay options

Option 2: Tor Onion Relays: Some relays offer .onion addresses (Tor-only):

ws://relay...onion

Pros: Maximum anonymity, relay designed for Tor Cons: Limited availability, setup complexity

Option 3: System-Wide Tor (Advanced):

Configure OS to route all traffic through Tor
Use any Nostr client
Requires technical knowledge

Best Practices with Tor:

Never mix Tor and non-Tor activity on same identity
Don’t login to real-identity accounts over Tor
Understand Tor’s limitations (can’t protect application-level leaks)
Be patient with slow speeds

Encrypted Direct Messages

Nostr supports encrypted DMs via NIP-04, but understand the limitations.

How Nostr DMs Work

Encryption (NIP-04):

Your client encrypts message content using recipient’s public key
Encrypted message published to relays (kind:4 event)
Recipient’s client decrypts using their private key
Message content is private

What’s Encrypted:

✅ Message text content
✅ Message cannot be read by relays or observers

What’s NOT Encrypted (Visible Metadata):

❌ Sender public key (who sent it)
❌ Recipient public key (who received it)
❌ Timestamp (when sent)
❌ That a DM was sent (visible event kind)

DM Security Limitations

Known Issues:

Metadata Leakage: Everyone can see who messaged whom and when
No Forward Secrecy: If private key compromised, all past DMs readable
No Deniability: Signature proves you sent the message
Relay Persistence: Encrypted messages stored on relays indefinitely

Comparison to Signal/WhatsApp:

Signal has forward secrecy (Nostr doesn’t)
Signal has better metadata protection
Signal has message deletion
Signal designed for privacy; Nostr designed for openness

When to Use Nostr DMs:

✅ Casual private conversations
✅ Non-sensitive coordination
✅ Information not critically secret

When NOT to Use Nostr DMs:

❌ Highly sensitive information
❌ Conversations requiring deniability
❌ When metadata must be private
❌ Legal/security-critical communication

Better Alternatives for Sensitive Communication:

Signal (mobile messaging, strong privacy)
Session (decentralized, metadata protection)
SimpleX (maximum metadata privacy)
PGP Email (established, but complex)

NIP-04 Alternatives (Future)

NIP-17 (Private Direct Messages) - In Development:

Improved DM encryption
Better metadata protection
Gift-wrapped events
Forward secrecy considerations

Status: Proposed, limited implementation Future: May address current NIP-04 limitations

Relay Privacy Considerations

Relays are a privacy double-edged sword.

What Relays Know About You

Information Visible to Relay Operators:

Your IP address (unless using VPN/Tor)
Connection times and duration
Events you publish (content is public anyway)
Events you request (reveals interests)
DM metadata (who you message, when)

Relays Can:

Log all of this information
Sell/share data
Correlate your activity
Be compelled by law to provide data

Relays Cannot:

Read encrypted DM content (they see encrypted blobs)
Modify your signed events (signatures would break)
Steal your private key (if you use browser extensions)

Choosing Privacy-Conscious Relays

Evaluation Criteria:

Operator Reputation:
- Known operator vs. anonymous
- Privacy policy (if stated)
- Location/jurisdiction
Privacy Policies:
- Do they log IP addresses?
- Do they retain logs long-term?
- Do they sell data?
- Would they comply with legal requests?
Technical Setup:
- Onion address available (Tor support)?
- Proper TLS/WSS security?
- DDoS protection revealing IP?
Geographic Distribution:
- Diversify across jurisdictions
- Avoid single-country concentration
- Consider legal climate

Privacy-Focused Relay Options:

Relays with .onion addresses (Tor)
Relays with explicit privacy policies
Relays in privacy-friendly jurisdictions
Paid relays (less incentive to monetize data)

Anti-Privacy Relay Patterns:

Relays that require real identity (email, phone)
Free relays with unclear business model
Relays operated by data companies
Relays with no privacy policy

Relay Diversification for Privacy

Strategy:

Use 5-10 relays minimum
Mix geographic locations
Mix paid and free
Mix general and specialized
Rotate periodically

Don’t:

Use only one relay (single point of surveillance)
Use only relays in one country
Share all relay lists between identities

Image and Media Privacy

Media files can leak significant metadata.

EXIF Data Removal

What EXIF Contains:

GPS coordinates (exact location)
Camera model
Timestamp
Software used
Sometimes: photographer name, copyright

Before Posting Any Image:

Check for EXIF:
- Use EXIF viewer tool
- Check image properties
Remove EXIF:
- exiftool (command-line): exiftool -all= image.jpg
- ImageOptim (Mac): Automatic EXIF stripping
- ExifCleaner (Windows/Mac/Linux): GUI tool
- Online tools (less secure, use offline tools for privacy)
Verify Removal:
- Check image again with EXIF viewer
- Confirm GPS coordinates gone

Content-Based Privacy

Beyond metadata, image content reveals information:

Visual Information:

Faces (yours, others’)
License plates
Street signs (location)
Landmarks
Documents/screens in background
Reflections in glasses/mirrors

Best Practices:

Blur faces (yours and others’)
Crop out identifying elements
Avoid unique locations
Check reflections
Consider what’s in the background

Client Privacy Features

Different clients offer different privacy features.

Privacy-Focused Clients

Features to Look For:

Tor support
VPN compatibility
Metadata minimization
No telemetry/analytics
Local-only key storage
Privacy-focused defaults

Client Comparison (Privacy Features):

Client	Tor Support	Metadata Minimal	Open Source	Key Storage
Damus (iOS)	❌	✅	✅	Secure Enclave
Amethyst (Android)	⚠️ (via Orbot)	✅	✅	KeyStore
Snort (Web)	✅ (Tor Browser)	✅	✅	Extension
Iris (Web)	✅ (Tor Browser)	⚠️	✅	Extension

Privacy Settings to Configure

In Most Clients:

Profile Privacy:
- Minimize profile information
- Generic avatar
- No location
- No website (if privacy-focused identity)
Content Privacy:
- Disable automatic media loading (prevents IP leakage to image hosts)
- Review posts before publishing
- Don’t auto-share location
Network Privacy:
- Review relay list
- Add privacy-focused relays
- Remove relays you don’t trust
Metadata Privacy:
- Disable read receipts (if client has them)
- Disable typing indicators
- Review what metadata client sends

Operational Security (OPSEC)

Day-to-day privacy practices matter.

Device Security

Mobile:

Use device encryption
Strong PIN/biometric
Keep OS updated
Only install from official stores
Review app permissions

Desktop:

Full disk encryption
Secure boot
Separate user accounts for different identities
Virtual machines for high-security identities

Account Separation

Never Mix Identities:

Don’t follow same people across identities
Don’t post about same topics
Don’t use same devices/IPs (if possible)
Don’t use similar writing styles

Physical Separation:

Different devices for different identities (ideal)
Different browsers for different identities (minimum)
Different relay lists
Different client applications

Communication Discipline

What Not to Share:

Real name (pseudonymous identities)
Location details
Personal schedule
Work/school information
Family/friend details
Photos containing metadata

Safe Sharing:

Generic opinions
Non-identifying interests
Content without metadata
Information already public elsewhere (if not linking identities)

Privacy Checklist

For Basic Privacy

Using pseudonym (not real name)
Profile has no identifying information
EXIF data removed from all images
Using reputable VPN
Diversified relay selection (5+ relays)
Understanding that posts are public
Not revealing location in content

For Enhanced Privacy

Tor browser for web access
Multiple identities for compartmentalization
Different devices/browsers per identity
Privacy-focused relay selection
Regular metadata review
Avoiding timing patterns
No cross-identity contamination

For Maximum Privacy

Privacy vs. Convenience Trade-Offs

The Reality: Privacy requires sacrifice.

Easy (Low Privacy Cost):

Using a VPN
Removing EXIF from images
Using pseudonyms
Basic relay diversification

Moderate (Medium Privacy Cost):

Tor browser usage (slower)
Multiple identity management (complex)
Content discipline (restrictive)
Timing randomization (inconvenient)

Difficult (High Privacy Cost):

Maximum operational security (paranoid, tiring)
Perfect identity separation (very complex)
Tor-only access (very slow)
Disposable identities (lose network effects)

Choose your trade-offs consciously based on your threat model.

UK-Specific Privacy Considerations

Legal Context

Online Safety Act 2023:

Primarily targets platforms (not decentralized protocols)
UK-based relays might face compliance pressure
Your identity/content globally distributed (beyond UK law)

Data Protection:

GDPR doesn’t cleanly apply (no data controller)
Public posts are public (no “right to be forgotten” on decentralized relays)
Consider using non-UK relays

Practical UK Privacy

For UK Users Seeking Privacy:

Use relays outside UK jurisdiction
Use VPN/Tor to hide UK IP
Understand UK ISPs can see Nostr usage (VPN prevents)
Consider using privacy-friendly jurisdictions (Switzerland, Iceland, etc.)

Conclusion

Privacy on Nostr requires active effort and continuous vigilance. The protocol is built for censorship resistance, not privacy, so you must layer privacy practices on top.

Key Takeaways:

Understand what’s public: Assume everything is public unless proven otherwise
Choose your threat model: Privacy requirements vary widely
Layer protections: VPN + metadata discipline + operational security
Accept trade-offs: Maximum privacy requires sacrificing convenience
Stay vigilant: One mistake can compromise pseudonymous identity

Nostr can be used privately, but it requires knowledge, discipline, and realistic expectations.

Your privacy is your responsibility. The protocol won’t protect you—only your practices will.

Further Resources

Security Best Practices - Overall Nostr security guide
Key Management - Protecting your private keys
How Nostr Works - Understanding the protocol
NIP-04 Specification - Encrypted DMs (current standard)
Tor Project - Network anonymity tool

Remember: Privacy is a spectrum, not a binary. Choose your level consciously and maintain it consistently. 🔒🕵️