Sovereign Nostr Operations Manual (v1.0)

Protocol, not platform. Event bus, not app.

0. Scope & stance

This manual treats Nostr as:

• A censorship-resistant, open protocol for signed events over relays (see the core repo on GitHub: nostr-protocol/nostr).
• A public, surveilled substrate that is already being harvested by dashboards, scrapers, and AI systems (see e.g. nostr.com).

Non-goals (very important):

• Nostr is not a privacy protocol.
• Nostr is not an anonymity system.
• Nostr is not a safe channel for high-risk operational secrets, even with DMs.
• Nostr is not immune to AI/OSINT aggregation.

Everything below is about using it on those terms.

1. Nostr in one page

1.1 Core model

Nostr (“Notes and Other Stuff Transmitted by Relays”) is an open protocol for decentralized message transmission designed to resist censorship while maintaining session integrity (see the overview on Wikipedia).

Mechanics:

• You have a keypair (npub / nsec) as your identity.
• You create events (JSON blobs) signed with your private key.
• You send events to relays (WebSocket servers) (protocol spec).
• Clients connect to relays, filter events, and render them as feeds, DMs, long-form posts, markets, etc.

The protocol itself is deliberately minimal — it just defines the messages between clients and relays.

1.2 What Nostr is good at

From the protocol’s own framing and independent overviews:

• Smart client / dumb server architecture — relays are simple; logic lives in clients (framed on nostr.org).
• Censorship resistance at the protocol level — no single relay or company can block the protocol itself (Wikipedia).
• Identity portability — your npub works across any client and relay that speaks the protocol (see the Nostr Developer Guide).

1.3 What Nostr is not

Protocol-level docs, security write-ups, and NIP DM specs are explicit:

• DMs (NIP-04, NIP-44) leak metadata and are not suitable for strong-adversary secrecy (see e.g. Nostr Security & Privacy Tips – Ron Stoner).
• Relays see IPs, timing, and event metadata unless you hide them (Tor, VPN, private relays).
• Content is routinely archived and indexed; “delete” is at best best-effort, never guaranteed.

Treat Nostr like a global signed radio, not a confidential messenger.

2. Threat model & personas

Design your usage around personas, not “one account does everything”.

2.1 Persona types

1. Signal persona (public / loud)
   • Purpose: public writing, teaching, content broadcasting.
   • Accepts: being searchable, quotable, scraped, used in AI training.
   • Tools: NIP-05, zaps, V4V, public relays.
2. Operator persona (sovereign / controlled)
   • Purpose: organizing, building, coordinating communities or projects.
   • Accepts: some exposure, but with careful relay/Lightning choices and compartmentalization.
3. Ghost persona (high-risk / low-signal)
   • Purpose: observation, low-attribution signaling, experimental ops.
   • Requires: strict key isolation, minimal metadata exhaust, compartmentalized devices and relays, and often non-Nostr channels for truly sensitive content.

For each persona, everything that follows (keys, relays, clients, Lightning) must be explicitly specified, not left to defaults.

3. Identities & keys

3.1 Core facts

• Your “account” is your keypair; lose or leak the nsec and that identity is gone or compromised forever.
• Most early clients asked users to paste nsecs into web UIs or extensions — exactly the scenario early security warnings targeted (see Ron Stoner’s security note).

3.2 Baseline key protocol

For any identity that matters:

• Generate keys locally on a machine you control (CLI tool, offline device, or a hardened signer).
• Store nsec encrypted, not in plain text:
  • Local password manager (strongly secured),
  • Hardware password vault,
  • Offline backups (paper, hardware) for disaster recovery.
• Never paste nsec into random websites or untrusted extensions; if something online asks for your private key, treat that as a red flag.

3.3 NIP-46 / remote signing baseline

For real identities, NIP-46 (“Nostr Connect”) / remote signing should be treated as baseline, not an optional luxury:

• The signer holds the keys; clients send unsigned events and get back signatures.
• If a client or browser is compromised, your keys remain in the signer, not exfiltrated.

Operational rule: nsec lives in a signer; clients never see it directly, except for short-lived burner identities.

4. Identity binding & correlation (NIP-05, bridges, DID)

4.1 NIP-05 (DNS name ↔ Nostr key)

NIP-05 maps name@domain ↔ npub via a DNS-hosted JSON file and HTTPS. It’s widely promoted to make identities “human readable” (see, for example, the explanation at nostr.co.uk – How Nostr Works and the NIPs list).

Risk:

• DNS + web hosting + identity providers become centralized chokepoints.
• Any NIP-05 mapped to your legal-name domain or email ties your Nostr persona to real-world identity.

Guideline:

• Signal persona: NIP-05 is acceptable (even useful) if you accept that it’s doxxed and centralized.
• Operator / ghost persona: either skip NIP-05 or self-host under hardened, compartmentalized infra and still assume it can be pressured.

4.2 Social and app bridges

There are tools and projects mapping:

• Twitter / X handles → npubs.
• Web domains / profiles → npubs.
• Nostr keys → DIDs so they can plug into decentralized identity and verifiable credential ecosystems (see the Nostr Dev Guide for identity discussions).

Result: your Nostr identity does not live in isolation. Default usage tends to bind it into a multi-graph linking DNS, email, social, payments, and DID infrastructure.

Design identities with that in mind.

5. Clients & signers

5.1 Clients are interfaces, not “accounts”

The protocol defines messages; clients are just tools (core spec).

Implications:

• Never let a client “own” your identity (e.g., by giving it unique access to your only key).
• Maintain at least one alternative client/signer path for each key.

5.2 Normie on-ramp vs sovereign setup

Normie path (for onboarding others)

Good references:

• nostr.how – Get started with Nostr: create a Lightning wallet, generate an account, sign into a client safely.
• start.nostr.net: simple, guided key generation and profile creation.

These often assume:

• Key generation in browser or extension,
• Use of browser extension signers like Alby,
• Web clients (Iris, Astral, Snort, etc.).

This is fine for intro and low-risk usage, not for core sovereign identities.

Sovereign path (for you / operators)

• Use dedicated signers (desktop daemon, hardware, NIP-46-based service).
• Use multiple clients (desktop + mobile + maybe web) all talking to the signer.
• Treat browser extensions and web clients as low-trust surfaces — appropriate for burners or casual use, not deep ops.

6. Relays & topology

6.1 What relays actually do

Relays:

• Accept events, store them (maybe), and send them to subscribers (spec).
• Have policies about what they take, store, or drop (POW, whitelists, pruning, etc.).
• Are monitored and indexed by third-party dashboards for uptime, latency, and traffic, such as nostr.info, nostr.watch, and nostr.band.

6.2 Relay zones

Think of three “zones”:

1. Public Broadcast Zone
   • Big public relays, commonly seen in directories like nostr.net and Awesome Nostr.
   • Maximum reach, maximum surveillance.
2. Community / Semi-Private Zone
   • Relays run by your community or allies, possibly invite-only.
   • Still assume they can be scraped, but at least you know the operator.
3. Internal / Lab Zone
   • Relays you run exclusively for:
     • Infra testing,
     • Internal bots,
     • Off-public experimental traffic,
     • Archival or mirroring.

6.3 Operational relay policy

Per identity:

• Define a short, deliberate relay list:
  • 1–3 public relays for reach,
  • 1+ community/in-house relays for resilience,
  • Optional private ones for scoped traffic.
• Periodically audit:
  • Are relays still up?
  • Are they silently censoring?
  • Are they reachable from your target audience’s clients?

Relay defaults from clients are starting points, not gospel.

7. Security & privacy practices

7.1 DM & encryption reality

From NIP-04, NIP-44, and early security write-ups:

• Confidentiality limitations:
  • Early DMs (NIP-04) use basic ECDH and are explicitly labeled not suitable for serious secrecy.
  • NIP-44 improves encryption but cannot guarantee long-term secrecy against strong adversaries.
• Metadata leakage:
  • Relays see sender pubkey, recipient pubkey, timestamps, and possibly content length.
  • This alone enables powerful traffic analysis.

Operational rule: use Nostr DMs for low-risk social messaging and contact bootstrap, not for sensitive ops. For high-risk comms, use purpose-built E2EE (Signal, Matrix, off-band) and treat Nostr as the “directory” layer.

7.2 Key & client attacks

Concrete risks highlighted by security practitioners:

• Users pasting nsec into multiple web clients → phishing & exfiltration.
• Malicious / compromised clients silently:
  • Swapping relays,
  • Backdooring events,
  • Draining Lightning wallets if integrated.

Mitigations:

• Remote signing (NIP-46) for serious identities.
• Minimal client set per identity; audit updates and provenance.
• No “all eggs in one browser extension.”

7.3 Known attacks & research

There is an emerging catalog of real-world attacks:

• Curated lists of Nostr attacks, such as github.com/ronaldstoner/nostr-attacks.
• Security blog posts and conference talks exploring:
  • DM decryption in specific client implementations,
  • Relay-level censorship and injection,
  • Micro-payment hijacking in flawed wallet integrations.

Treat these as required reading for anyone building or operating key infrastructure.

8. Metadata, OSINT, and AI

8.1 Aggregators & dashboards

Sites like nostr.info, nostr.watch, nostr.band, and others:

• Monitor relay status, stats, and usage patterns.
• Make it trivial to see which relays are most used, which clients connect, and which pubkeys are active.

These tools are dual-use:

• You can use them to monitor your infra and reach.
• Adversaries can use them to build OSINT dashboards and target graphs.

8.2 AI & federation

Academic and commercial work already explores Nostr as AI substrate. For example, Fedstr proposes a decentralized marketplace for federated learning and LLM training built on Nostr, with datasets and model updates exchanged via events.

Combined with:

• LLM summarizers and bots feeding Nostr events into models,
• JSON-LD / RDF mappings (e.g. Nostr-LD, discussed in resources like Nostrbook) that turn events into semantic graph nodes.

Practical conclusion: assume anything you publish on public relays becomes structured AI training data and searchable knowledge graph content.

Design what you emit accordingly.

9. Lightning, zaps, and value flows

9.1 Why Lightning integration matters

Guides and learning paths emphasize Lightning wallets and “zaps” as central to Nostr’s value-for-value ecosystem (e.g. the Lightning & zaps sections in nostr.how and LearnNostr).

Zaps do three things at once:

• Move sats,
• Signal value and attention,
• Create high-quality correlation edges between pubkeys and Lightning endpoints.

9.2 Custodial vs non-custodial

Educational resources like LearnNostr lay out tradeoffs:

• Custodial wallets:
  • Easy setup, low friction,
  • But provider can see, block, or report flows; often KYC’d.
• Non-custodial wallets:
  • More control, higher privacy,
  • Operational complexity and on-chain funding requirements.

Operational rules:

• Signal persona: can accept custodial zaps if they accept the surveillance tradeoff.
• Operator / ghost persona:
  • Prefer non-custodial setups,
  • Use fresh, well-isolated Lightning addresses,
  • Or avoid direct inbound zaps; use alternative value routing (e.g., Bitcoin addresses communicated off-band).

10. Ecosystem maps & learning resources

10.1 High-level overviews (mental model)

Use these to install the protocol model and macro framing:

• nostr.org – Get Nostr!: official landing with smart client / dumb server framing, relays, public-key cryptography, and user data control.
• nostr.com: frames Nostr as “an open social protocol with a chance of working” and “inclusive communication commons.”
• Nostr Developer Guide / Nostrbook: structured protocol docs and explanations that sit on top of NIPs (identity, events, relays, etc.).

10.2 Directories & indexes (use as maps, not endorsements)

• Awesome Nostr / nostr.net – curated list of clients, relays, tools, libraries, and more.
• nostr-resources.com – high-level intro with “Get Started”, “Learn More”, and “Tools” sections (Nostr Metadata, NostrSync, Nostr Follows, Nostr Delete).

Treat these as ecosystem indexes you query when you want classes of tools, and as OSINT surfaces that show adversaries the same information.

10.3 Structured learning

LearnNostr provides a guided path from basics to building applications:

• Protocol fundamentals,
• Keys & identity,
• Lightning integration,
• Developer tools & infra (“Nostr tools” module).

Use it as a curriculum for training operators and developers — then layer your threat model on top.

11. Builders: dev & design stack

11.1 Developer tooling

For building clients, relays, agents, or infra:

• Libraries like nostr-tools, NDK, nostr-sdk, nostril, etc. are catalogued in Awesome Nostr and in LearnNostr’s “Nostr tools” section.
• nostr.co.uk – Build on Nostr lists libraries, docs, and developer tools in a single hub.

Guidelines:

• Check maintenance status and ownership of any library you adopt.
• Avoid hidden dependencies on centralized infra (e.g., a library silently hard-coding a single relay or analytics endpoint).

11.2 UX & product design

Nostr Design provides principles and patterns for:

• Onboarding,
• Key handling,
• Identity,
• Relays,
• Zaps and interactions.

Use it to:

• Make UX honest about what’s happening (keys, relays, identity exposure).
• Avoid replicating Web2 illusions (e.g., “accounts on our service” instead of “npub + relays”).

For sovereign design:

• Prefer flows that teach protocol reality while still being usable.
• Avoid patterns that centralize power (single default relay, single recommended signer, opaque search).

12. Beyond social: Nostr as event bus

Nostr isn’t just Twitter-but-signed.

Ecosystem catalogs and research describe:

• Messaging, DMs, blogging, podcasts, streaming, marketplaces, collaborative tools.
• JSON-LD / Nostr-LD as a bridge to semantic web and knowledge graphs (see documentation and examples linked from Nostrbook and related projects).
• Systems like Fedstr, treating Nostr as a backbone for federated learning and LLM marketplaces.

From a systems perspective:

• Nostr = generic signed event bus.
• Social apps are one application; others include:
  • Offers / acceptances (private law signaling),
  • Coordination feeds for markets or DAOs,
  • Notification / alert channels for infra,
  • Metadata plane for federated or P2P systems.

This is where it can become part of a broader sovereign stack — as long as you treat its public nature seriously.

13. Onboarding others (controlled)

For pulling people out of Web2 without misleading them:

• Use accessible guides for conceptual onboarding:
  • nostr.how – Get Started
  • LearnNostr – Intro modules
• Immediately inject:
  • “This is public and surveilled.”
  • “This is protocol, not platform.”
  • Basic key and relay hygiene.

Provide a two-stage path:

1. Stage 1 – Experience
   • One mobile client + one simple signer (even extension-based) + a handful of relays.
   • Limited Lightning usage.
2. Stage 2 – Sovereignty
   • Remote signing, multiple clients, chosen relays,
   • Non-custodial Lightning,
   • Awareness of metadata and AI/OSINT surfaces.

14. Re-audit checklist (keep the guide alive)

Revisit these questions regularly (every few months):

1. New NIPs & governance
   • Which new NIPs have merged in the nostr-protocol/nips repo?
   • Do any centralize identity, search, or moderation in ways you reject?
2. Relays & indexes
   • Which relays and search/index services have become dominant?
   • Are they biasing discovery or suppressing certain content?
3. AI & OSINT
   • What new projects are feeding Nostr into AI/LLM pipelines (beyond things like Fedstr)?
   • Are any commercial OSINT suites integrating Nostr as a standard feed?
4. Security
   • Have curated attack lists like nostr-attacks been updated?
   • Any major client or signer vulnerabilities discovered?
5. Lightning & regulation
   • Have major custodial providers changed policies on zaps / Nostr integration?
   • Any new non-custodial setups improving privacy?
6. App distribution
   • Any significant app store bans, restrictions, or forced changes for popular clients?

Treat this manual as living infrastructure, not dogma. The protocol is simple; the ecosystem, incentives, and threats are not.