Nostr Social Client Set

One framework, one ranking, one coherent picture of this Nostr social client set from a sovereignty / FOSS / privacy-maximal lens.

S-tier: instruments, not platforms A-tier: strong with non-trivial risks C-tier: structurally centralizing stacks

Contents

↑ back to contents

1. Executive summary

We’re judging every social client on one thing: does it preserve or erode sovereignty?

Final shape:

The ranking is not about polish; it’s about how hard each tool tries to pull you back into soft Web2 patterns and central infra.

↑ back to contents

2. Telos & threat model

2.1 Telos

Underlying assumptions baked into the scoring:

  1. Keys never leave local or explicitly chosen signers.
  2. Relays are interchangeable commodities, not feudal lords.
  3. Clients are replaceable shells, not sovereign truth sources.
  4. Bitcoin alignment (LN, NWC, no shitcoins) is positive.
  5. FOSS is mandatory; any “source-available but NC” stuff is a smell.
  6. No central graph/trust/caching oracle should define your reality.
  7. No protocol bridges unless explicitly cordoned off as high-risk.

2.2 Adversary model

We assume adversaries that:

“If someone compromised this client + its natural infra neighbours, how much could they distort or surveil your view of Nostr?”
↑ back to contents

3. Evaluation framework

Each client is scored 0–10 on five axes, then averaged into a Fractal Sovereignty Score (FSS).

3.1 Architecture Sovereignty (A)

  • Keys: local vs remote; any custodial flows?
  • Full FOSS with OSI license? Any non-free bits in distributed builds?
  • Can the client operate in a pure “client <-> relays” mode without special services?

High = 10: local keys, fully FOSS, no required cloud.
Low = 0: custodied keys, proprietary backend.

3.2 Infra Centralization Risk (I)

  • Does it depend on a caching/indexing layer between you and relays?
  • Does it lean on official relays as the expected environment?
  • Does it call graph/trust/WoT services that aggregate the social graph?
  • Is it a vertical stack of infra under one operator?

High = 10: talks to arbitrary relays, no privileged middlebox.
Low = 0: thick middlebox / vertical stack is the real substrate.

3.3 Privacy & Data Posture (P)

  • App-store “data safety” declarations.
  • Statements about analytics, logging, crash reporting (or lack thereof).
  • Tor/proxy support and self-hosting options.
  • How much unavoidable metadata hits first-party infra by default.

High = 10: no data collected, no analytics, easy to hide behind Tor/self-host.
Low = 0: tracking/telemetry/opaque policies.

3.4 Sovereign Power UX (X)

  • Fine-grained relay control; multiple profiles and sets.
  • Raw event views, debugging views, identity tooling.
  • Ease of using signers, wallets, Bitcoin features without getting trapped.

High = 10: power-tool for relay/graph control.
Low = 0: toy UI hiding critical controls.

3.5 Narrative / Dogma Risk (D)

  • “Safety / community health” baked into topology and discovery.
  • Engagement-driven “For You” feeds, trending, opaque recommendation logic.
  • Fixed 2-hop limits or curated nets masquerading as “for humans”.

High = 10: chronological / explicit filtering, no disguised ideology.
Low = 0: soft ideological cage.

↑ back to contents

4. Final ranking

4.1 Summary table

Client Tier A I P X D FSS
GossipS101099109.6
noStrudelS910810109.4
JumbleS91089109.2
AmethystS9910999.2
LumilumiS91088109.0
DamusA889998.6
NosotrosA9987108.6
NosturA879988.2
NostrmoA878988.0
YakihonneA878988.0
SnortA878887.8
CoracleA888877.8
IrisA777887.4
NostriaC647966.4
PrimalC637966.2
Nos SocialC547845.6

S-tier = best aligned with sovereignty telos.
A-tier = usable by a sovereignty-maxi with clear constraints.
C-tier = fundamentally infra/bridge stacks; useful for reconnaissance or normies, not for sovereign identity.

↑ back to contents

5. Per-client analysis

S-tier

5.1 Gossip — desktop sovereign node S FSS 9.6
  • A: Pure “client <-> relays” model. No mandatory infra, no caching middlebox. Local keys. Fully FOSS.
  • I: Outbox heuristics exist, but they’re local. No remote graph/trust server. Infra centralization ~0.
  • P: Desktop environment; no analytics stack baked in. Remaining risk is OS-level telemetry and binary supply chain, not client design.
  • X: Deep relay/event views, local trust labels, serious tooling. Very high.
  • D: No “safe network”, no curated 2-hop world, no algorithmic feed. All filters are explicit.

Net: this is the canonical sovereign workstation. “Instrument, not platform” archetype.

5.2 noStrudel — protocol & event explorer S FSS 9.4
  • A: Web client, MIT-licensed, no required backend except your relays and any optional hosts you configure.
  • I: No de facto central caching or graph engine; Wasm relay in-browser signals client-side work.
  • P: Host domain sees metadata unless self-hosted/Tor’d; generic web reality.
  • X: Strong: raw event views, sandboxes, plenty of levers.
  • D: Zero “here’s what’s hot, trust us” energy.

Net: neutral explorer / debugger / backup client; strong teaching tool for Nostr internals.

5.3 Jumble — topology navigator S FSS 9.2
  • A: FOSS relay-centric client. Local keys. Relays configured explicitly, not via a centralized profile service.
  • I: Built to explore relays/relay groups. No caching layer controlling what you see.
  • P: Web metadata to hosting domain without Tor; self-hosting mitigates.
  • X: Extremely high for relay operations. You shape topology directly.
  • D: Tools, not narratives. No ideology encoded as UX.

Net: relay-ops console; direct control over topology.

5.4 Amethyst — Android sovereign workhorse S FSS 9.2
  • A: MIT, local keys, optional signers, Tor support. No mandatory account or vendor relay.
  • I: Uses relays you configure; no hardwired caching/graph engine. Some trust/spam features, but local/optional.
  • P: “No data collected” claim; telemetry risk mainly from platform + future drift.
  • X: Very good: advanced relay/user controls, NIP support, Bitcoin integration.
  • D: Filtering exists but not as a single “true feed”; no normative wall-garden.

Net: top Android client for sovereign use; watch future updates for telemetry or remote-trust creep.

5.5 Lumilumi — quiet sovereign web UI S FSS 9.0
  • A: MIT web client; no hidden infra; relies on user-chosen relays/search relays.
  • I: Minimal; no thick middlebox, no vertical stack.
  • P: Standard web metadata issues only; otherwise light.
  • X: Solid but not as deep as Gossip/noStrudel; sufficient for relays/lists.
  • D: No safety-narrative gating.

Net: low-noise sovereignty-compatible generalist client.

A-tier

5.6 Damus — Apple-gated, but still solid A FSS 8.6
  • A: GPL, local keys, Nostr-native. No signups.
  • I: Official relay + push infra become soft defaults; centralization vector.
  • P: Claims minimal collection; Apple environment leaks device-level metadata.
  • X: Good relay list editing, multi-relay, solid posting UX.
  • D: No For-You feed; narrative risk low.

Net: strong client; ecosystem infra + Apple gatekeeping are real surfaces.

5.7 Nosotros — clean, minimal web client A FSS 8.6
  • A: Straightforward FOSS client; no weird infra attached.
  • I: Ecosystem includes external trust engines, but client can run without them; manageable if treated as optional.
  • P: Generic web + relay metadata exposure.
  • X: Feature-light but respectable; basic usage without “dumb” constraints.
  • D: No “safe world” narrative baked in.

Net: clean minimum client; simple but not toy-grade.

5.8 Nostur — iOS smart client A FSS 8.2
  • A: GPL, local keys, multi-relay.
  • I: WoT spam filtering + Relay Autopilot: client decides relay topology; convergence risk.
  • P: Store claims + iOS baseline telemetry.
  • X: Very good columns/feeds/controls.
  • D: Mild normative pressure via auto-curated graph; not full wall-garden.

Net: good Apple client if autopilot/WoT treated as tools, not truth.

5.9 Nostrmo — cross-platform Flutter client A FSS 8.0
  • A: GPL; local keys; standard relay behavior.
  • I: Supports index relays; risk depends on your choices; no forced infra.
  • P: No explicit “no data collected” promises; risk moderate pending audits.
  • X: Strong multi-platform key/relay control.
  • D: No heavy narrative gating.

Net: useful daily driver in a many-clients stack; merits binary/traffic audits.

5.10 Yakihonne — long-form + programmable A FSS 8.0
  • A: FOSS, multi-platform, Bitcoin-heavy.
  • I: Operates its own relays for long-form/content; algorithms/MiniApps increase infra reliance.
  • P: Listings say no data collection; central relays still see interactions.
  • X: Very high for creators: dashboards, curated feeds, MiniApps.
  • D: Platform-ish; curation shapes attention.

Net: great for publishing/discovery if treated as media platform, not reality layer.

5.11 Snort — fast but gravitating around its relay A FSS 7.8
  • A: Open-source web client; local keys.
  • I: Gravity around an official relay + subscription model; diversify relays to avoid monoculture.
  • P: Policy claims minimal collection; default infra still matters.
  • X: Good lists/multi-relay/UX.
  • D: Trending exists but not full engagement casino.

Net: reliable polished web client; avoid letting official relay become your gate.

5.12 Coracle — WoT / moderation lab A FSS 7.8
  • A: MIT; client talks to relays; moderation via events, not hidden DB.
  • I: WoT infra can become de facto trust oracles; risk sits a layer up from client.
  • P: Standard web + relay metadata; no extra tracking spotlighted.
  • X: Strong lists/trust/mod tools.
  • D: Normative dimension: moderation/WoT encodes opinions about actors.

Net: excellent for trust experiments; shared WoT services risk a soft permission layer.

5.13 Iris — offline-first with central graph service A FSS 7.4
  • A: MIT, offline-first, local DB.
  • I: Central graph service computes social graph; convenience + monoculture risk.
  • P: Normal web metadata exposure.
  • X: Well-designed UX.
  • D: Modern social UI feel without full engagement casino.

Net: strong architecture but conceptually welded to a graph oracle; treat graph as optional.

C-tier

5.14 Nostria — Nostr-as-a-service C FSS 6.4
  • A: FOSS client, tightly coupled to large infra footprint (discovery relays, user relays, media hosting, AI).
  • I: Vertical stack: operator relays + pools + backups; classic centralization with Nostr branding.
  • P: Operator sees a lot; policies/jurisdictions dominate risk profile.
  • X: Extremely feature-rich; powerful “platform” experience.
  • D: Convenience-driven normative gravity: “we run everything, trust us.”

Net: good for onboarding; keep at edges for sovereign identity.

5.15 Primal — high-end UX, thick caching middlebox C FSS 6.2
  • A: Clients and caching infra open-sourced; transparent architecture.
  • I: Caching/indexing servers sit between client and relays; huge centralization lever.
  • P: Caching sees almost everything unless intentionally bypassed.
  • X: Superb UX; excellent stats/discovery.
  • D: Feeds/trends emerge from middlebox; narrative power lives there.

Net: treat as search/analytics layer you dip into, not main client or graph oracle.

5.16 Nos Social — cross-protocol correlation engine C FSS 5.6
  • A: FOSS client.
  • I: Built around bridges (Nostr ↔ Mastodon ↔ Bluesky); bridge servers are observation towers.
  • P: Bridges can correlate identities across pseudonyms; correlation is structural risk.
  • X: Nice UI; convenient multi-network view.
  • D: Explicit normative “safe/community/2-hop” design; topologically constrained.

Net: only for fully public throwaway identities; adversarial terrain for ghost/high-stakes presence.

↑ back to contents

6. Practical architecture implications

If the goal is high-signal, low-simulation, collapse-ready use of Nostr:

Core tools (daily backbone)

Specialized tools

High-risk / edge-of-stack