Skip to content

Candidates — Client–Relay / No-Persistent-Identifier

Validation status: Facts sourced (2026). Fit-vs-MPowerUP verdicts [HYPOTHESIS].

The "third shape": clients talk through dumb-ish relays that store-and-forward but (ideally) don't constitute the identity layer. The decisive teaching point: encrypted content is table stakes; the privacy differentiator is the identifier model. Nostr proves it negatively (E2E DMs that still leak who-talks-to-whom because identity is a persistent public key). SimpleX proves it positively (no persistent identifier at all). Relays generally do not sync each other.

SimpleX Chat ⭐ (strongest on this branch for MPowerUP's threat model)

  • One-liner: The first messaging network with no user identifiers of any kind — not even random ones — using unidirectional per-connection message queues.
  • Architecture: Client–relay. SMP servers relay messages, XFTP servers relay files; relays are non-federated (don't talk to each other, store no user records). Each 1:1 connection uses separate unidirectional queues with distinct per-queue IDs — a relay only ever sees a queue address, never a user. Messages held in memory, deleted after delivery. Up to n·(n−1) queues defeats social-graph reconstruction.
  • Identity: ✅ No persistent identifier — its defining property. No username, account, phone, or global ID. Contacts via one-time invite links/QR; identity is per-contact keypair material. Strongest "no-account" match in the survey.
  • Encryption: Content E2E via Signal double-ratchet (FS + break-in recovery) with post-quantum key exchange every ratchet step (Curve448) in 1:1; extra NaCl layer server↔recipient; TLS 1.2/1.3. ⚠️ Groups currently use non-PQ E2E.
  • Metadata: ✅ Best-in-survey by design — no global identifiers → relays can't build a who-DMs-whom graph. Honest limits: a relay still sees connecting-client IP (unless Tor), message timing, and sizes; an adversary controlling both queues of a pair could correlate. Metadata-resistant, not metadata-free.
  • Network identity: ⚠️ IP exposed to relays unless Tor is used (SOCKS to v3 hidden services, supported since v3.1+). No built-in onion routing of its own.
  • Offline: ⚠️ Strong store-and-forward (relays hold until fetched → both parties needn't be online), but no Bluetooth/Wi-Fi local mesh. No reachable relay = no delivery. Not internet-free.
  • Mobile: ✅ Native Android (Play/APK/F-Droid) + iOS; roadmap explicitly targets older Android + 32-bit CPUs — favorable for refurb. v6.5.4 (June 2026).
  • Battery: ⚠️/❌ The biggest risk — instant notifications keep a persistent background TCP connection (no FCM in privacy mode); real-world higher-drain reports exist. Large-group broadcast is O(members) per message ("very costly for traffic and battery"); the super-peers fix was still rolling out mid-2026.
  • License: ❌ AGPLv3 (apps + simplexmq core). Strong network-copyleft — a real constraint if embedded; viable only if MPowerUP is itself AGPL or keeps SimpleX at arm's length.
  • Maintenance (2026): ✅ Active, well-funded (Jack Dorsey's Asymmetric, GitHub Sponsors; preset servers also run by Flux). Low abandonment risk.
  • Embeddability: Haskell core (simplexmq + simplex-chat). Reuse is real but Haskell-centric + AGPL → integrating into a RN/TS app means running it as a component/process or reimplementing the protocol. Non-trivial.
  • Zones: content Strong (Medium for groups) / metadata Strong / network-identity Medium (Strong only with Tor).
  • Fit: offline ⚠️ (relay store-and-forward, no mesh) · E2E+local keys ✅ · no-server ✅/⚠️ (non-federated, self-hostable, but needs a relay) · identity ✅ ideal / groups ⚠️ — designed for small trusted groups, which actually matches the Circle concept well · vulnerable ⚠️ (no-identifier can confuse; no recovery if device lost) · battery ⚠️/❌ · refurb ✅ (explicit old-Android targeting).
  • Net read: [HYPOTHESIS] The strongest single candidate on metadata + identity, and its small-group model maps onto Circles. Three honest blockers: AGPLv3, battery (until super-peers), Haskell core (hard to embed in RN). Best as an interim referral and a design exemplar for the no-identifier property, rather than a drop-in component.
  • Sources: https://github.com/simplex-chat/simplex-chat · https://simplex.chat/blog/20250114-simplex-network-large-groups-privacy-preserving-content-moderation.html · https://freedom.tech/simplex-chat-review/ · https://en.wikipedia.org/wiki/SimpleX_Chat

Nostr (Damus / Amethyst / 0xchat)

  • One-liner: Minimalist client–relay protocol; users are stable public keys (npub) posting signed events to many independent relays. Excellent for public broadcast, structurally weak for private DMs.
  • Architecture: Relays are dumb stores accepting signed JSON events over WebSocket; relays do NOT sync — clients publish to / read from many relays (outbox model). Anyone can run a relay.
  • Identity: ⚠️ Persistent keypair (npub/nsec) — one stable, globally visible identity. Great for public social; exactly what leaks in DMs.
  • Encryption: Public events unencrypted (signed). DMs: legacy NIP-04 (leaked metadata) → modern NIP-44 v2 content + NIP-59 gift wrap / NIP-17 to hide sender. ❌ No forward secrecy in NIP-17/44; FS + PCS + real groups only via NIP-EE/Marmot (below).
  • Metadata: ⚠️ The cautionary tale. Every event has a public author pubkey + public timestamp (NIP-01). NIP-17/59 gift-wrap hides sender/recipient and randomizes timestamps (maturing through March 2026), but relays still see IP/timing/sizes, and any non-NIP-17 hop falls back to leaking. Lesson: encrypted content ≠ private when the identifier is public-by-default.
  • Network identity: ❌ IP exposed to relays by default; multi-relay publishing widens the surface; Tor/VPN is user-supplied.
  • Offline / mobile / battery: Relay store-and-forward (no mesh); Amethyst (native Android, very active) + 0xchat + Damus(iOS); ⚠️ multi-relay WebSockets cost battery.
  • License: ✅ Permissive — NIPs are CC0, nostr-tools MIT, Amethyst MIT. Best embeddability in the survey for a TS/RN stack.
  • Maintenance (2026): Very active, broad ecosystem, OpenSats/Dorsey-funded. High fragmentation (many half-implemented NIPs).
  • Zones: content Strong (no FS) / metadata Weak (Medium only for fully NIP-17 DMs) / network-identity Weak.
  • Fit: offline ⚠️ · E2E ✅ (but single stable key is a recovery/exposure liability) · no-server ✅ · keypair ⚠️ / no native private-group primitive (NIP-29 groups are public/relay-scoped — wrong for confidential Circles) · vulnerable ⚠️ — a public, permanent identity is a safety hazard for reentry/recovery/houselessness users (correlatable across all activity) · battery ⚠️ · refurb ✅.
  • Net read: Nostr's advantage for MPowerUP is embeddability + ecosystem (a future public/discovery Z2/Z3 layer), not privacy. For confidential Circles its identifier model is a liability for vulnerable users.
  • Sources: https://github.com/nostr-protocol/nips/blob/master/17.md · https://nips.nostr.com/59 · https://github.com/nostr-protocol/nips/blob/master/44.md · https://www.learnnostr.org/getting-started/nostr-tools

NIP-EE / Marmot (MLS-over-Nostr; client: White Noise)

  • One-liner: Gives Nostr real private groups with forward secrecy + post-compromise security by layering IETF MLS over Nostr identity + relays.
  • Encryption: ✅ Strongest group crypto on this branch — MLS provides E2E + FS + PCS, keys rotated after every group op. This is exactly what plain Nostr DMs lack.
  • Limits: ⚠️ Still rides Nostr relays (IP/timing/existence-of-traffic visible) on a persistent-pubkey discovery layer → better content/FS, not a fundamentally better metadata model; does not reach SimpleX's no-identifier property. Spec'd as MIP-00…05; impls in Rust (MDK) + TS (marmot-ts).
  • Maturity: ⚠️ Early — White Noise reference client is new/less battle-tested; Android maturity early in 2026; higher immaturity risk than SimpleX or core Nostr. Permissive, embeddable (marmot-ts fits RN).
  • Zones: content Strong (MLS, FS+PCS) / metadata Weak–Medium / network-identity Weak.
  • Net read: The one to watch for group confidentiality (the area it beats SimpleX and base Nostr), but too immature in 2026 to bet a vulnerable-user product on. The MLS protocol itself is the more directly useful takeaway — see protocols.
  • Sources: https://nips.nostr.com/EE · https://www.whitenoise.chat/

Branch takeaways

  1. The metadata lesson is concrete: Nostr gives strong content encryption yet leaks the social graph via persistent pubkeys + public timestamps. Don't let "E2E encrypted" satisfy MPowerUP's privacy bar.
  2. SimpleX is the strongest candidate on metadata + identity, and its small-group design maps onto Circles. Blockers: AGPLv3, battery, Haskell core.
  3. Nostr's value to MPowerUP is embeddability for a future public/discovery layer, not private messaging.
  4. None of this branch is internet-free — all are relay store-and-forward; none does local mesh. Strict offline-first must come from MPowerUP's own libp2p/Yjs layer or a Briar-style mesh, not from here.
  5. NIP-EE/Marmot = watch for group crypto; MLS itself = evaluate now (it's a standard, not tied to Nostr).