Skip to content

Candidates — Tor-Native / Metadata-Resistant

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

This branch is high-priority: the team flagged the Tor Project mission ("anonymity and privacy technologies for human rights and freedoms… unrestricted availability and use") as closely aligned with MPowerUP's safety→privacy→autonomy hierarchy for vulnerable users. See also Tor as infrastructure for Tor as a tool and running a relay as contribution.

Headline finding. Tor-based apps win decisively on the metadata and network-identity axes MPowerUP cares about — but they pay in battery and latency on budget Android, and almost all fail strict offline-first (Tor needs the internet). The one exception is Briar, which uniquely couples Tor with a Bluetooth/Wi-Fi local mesh — the closest substrate match to MPowerUP's full requirement set. Cwtch is the strongest pure-metadata-resistant group design but is funding-fragile.

Substrate

Tor + onion services

  • 3-hop onion routing; v3 onion services give a self-authenticating .onion (ed25519 keypair) with no IP exposure and no exit node. Onion-to-onion hides both IPs from each other → maps cleanly onto "keypair not account."
  • Limit: low-latency, not a mixnet → does not defeat a global passive adversary doing traffic-confirmation. Hides client IP from destination and destination from network; that is the guarantee.
  • Offline: none (internet-only) — the core mismatch with offline-first.
  • License: 3-clause BSD (permissive). Maintenance (2026): very active; funding partly OTF/USAGM-exposed (March 2025 US executive-order disruption to USAGM/OTF) → ecosystem-wide funding risk to watch.
  • Sources: https://www.torproject.org/ · https://blog.torproject.org/advancing-digital-rights-in-2026/

Arti (Rust Tor)

Orbot (Android)

  • Tor as an Android VPN/proxy — the standard way to route an app's traffic over Tor. Mature (~17.x, 2026).
  • ❌ Battery is the honest weak spot: a constant Tor connection + foreground service keeps CPU/radio out of deep sleep; the project ships explicit battery-optimization fixes precisely because it's a known problem. On an aged refurb battery this is material. No clean 2026 mAh benchmark — characterize as "significant," don't fabricate a number.
  • License: 3-clause BSD. Source: https://en.wikipedia.org/wiki/Orbot

Snowflake / I2P / Nym (substrate alternatives)

  • Snowflake — censorship-circumvention transport (volunteer WebRTC proxies → Tor). A reach layer, not anonymity. Relevant only in censored/blocked-network deployments. BSD, active.
  • I2P (i2pd 2.60.0, April 2026) — garlic-routed P2P overlay; keypair-native (b32 address). ⚠️ Worse mobile battery than Tor-client because every node also routes for others. No turnkey messenger. BSD.
  • Nym — decentralized mixnet (5-hop + cover traffic) → ✅ best-in-branch metadata/timing resistance, the only "Strong" on metadata against a global adversary. ❌ But: continuous cover traffic = battery/data-hostile; token/blockchain-incentivized (conflicts with free-to-vulnerable-users); NymVPN is a VPN, no messenger. File as "if global-adversary metadata resistance becomes dominant," not near-term.
  • Sources: https://nym.com/mixnet · https://github.com/PurpleI2P/i2pd · https://support.torproject.org/anti-censorship/what-is-snowflake/

Apps

Briar ⭐ (the standout for MPowerUP's full requirement set)

  • One-liner: Tor-based P2P messenger that also falls back to Bluetooth / Wi-Fi local mesh and USB/SD sneakernet — the only candidate that works with no internet at all. The team specifically asked to consider it (for Android).
  • Architecture: Direct encrypted device-to-device sync over Tor (online) OR Bluetooth/Wi-Fi (offline/local) OR USB/SD (sneakernet). Briar Mailbox = companion app on a spare/trusted device that holds messages for contacts who are online at different times (async delivery).
  • Identity: Keypair per device; contacts added by mutual key exchange (in-person QR or remote). No phone number, no account, no central directory. Contact list encrypted on-device.
  • Encryption: Content E2E via the Bramble protocol family (Bramble Transport/Sync/Handshake); newer Handshake protocol adds forward secrecy for contact links; transport keys rotate. Cure53-audited.
  • Metadata / network identity: Strong — no servers → no central party sees the graph; online traffic over Tor (IP hidden); offline traffic stays on local radios.
  • Offline: ✅ Best in the entire survey — explicitly designed for internet blackouts (Bluetooth + Wi-Fi mesh + sneakernet + Mailbox async). This is the differentiator and the reason Briar is the Z0 reference.
  • Mobile: ✅ Native, mature, Android-first (1.5.17, March 2026) — directly matches MPowerUP's budget-Android target. Desktop is secondary.
  • Battery: ⚠️ Persistent foreground service keeps Tor + Bluetooth/Wi-Fi discovery alive (no central push server → it must stay reachable itself). Real cost, but offline it avoids Tor's cost entirely by using local radios.
  • License: GPLv3 (copyleft) — a derived app must be GPLv3. The Bramble protocol is the reusable reference even if the app isn't embedded.
  • Maintenance (2026): Active (March 2026 release); grant-diversified (NLnet/NGI, OTF, Access Now), partially OTF-exposed. Not at near-term abandonment risk.
  • Zones: content Strong / metadata Strong / network-identity Strong (online) / N/A (offline-local).
  • Fit:
  • offline-first ✅ — the only candidate that genuinely does Bluetooth/Wi-Fi mesh + sneakernet.
  • E2E + local keys ✅ — keys on-device, no escrow, audited.
  • no central server ✅ — pure P2P; Mailbox is user-owned.
  • keypair + Circle model ⚠️ — keypair ✅; groups/forums exist but are feed/forum-style, not a tight Circle admin model — needs evaluation against MPowerUP's facilitator/member/observer roles.
  • vulnerable / low-literacy / budget-Android ⚠️ — Android-native + modest hardware ✅; in-person key exchange + no phone-number onboarding raise the usability floor.
  • battery-conscious ⚠️ — persistent service draws; mitigated offline.
  • refurb hardware ✅ — runs on old Android; Mailbox can live on a spare refurb device → synergistic with Second Boot.
  • Net read: [HYPOTHESIS] The closest existing app to MPowerUP's whole requirement set. The gaps are the Circle group-model fit, GPLv3 copyleft, and battery — not privacy or offline capability. Strongest candidate to study/fork/interoperate with, and an honest interim referral for users who need offline-resilient secure messaging today.
  • Sources: https://briarproject.org/how-it-works/ · https://briarproject.org/ · https://en.wikipedia.org/wiki/Briar_(software) · https://nlnet.nl/project/Briar/

Cwtch

  • One-liner: Metadata-resistant multi-party messaging over Tor v3 onion services; built by Open Privacy. The cleanest group metadata design in the branch.
  • Architecture: Every peer is reachable as a Tor v3 onion service; groups use discardable, untrusted, anonymous servers that anyone can run and that learn nothing (not even membership). No "Cwtch network"; fully self-hostable.
  • Identity: Onion-address keypair; mint as many anonymous identities as you want. No account/phone number.
  • Encryption: E2E (builds on Ricochet); group protocol layers extra encryption so the untrusted host sees only ciphertext.
  • Metadata / network identity: ✅ Strong on both — explicit design goal is "no protocol metadata available without consent"; all traffic over Tor (both IPs hidden).
  • Offline: ❌ Tor-only; no BLE mesh. Untrusted group server gives some async store-and-forward, but no internet = no Cwtch.
  • Mobile/battery: Native Android (Flutter, im.cwtch.flwtch), last app release ~1.16.1 (Sept 2025), protocol updated March 2026 → cadence slowed. ❌ Hosting your own onion service is the heaviest battery model here.
  • License: ✅ MIT-family (permissive) — libcwtch is explicitly a reusable library + reference app, the most "build-on-it" friendly app in the branch.
  • Maintenance (2026): ⚠️ The concern — small Canadian nonprofit, donation-funded, has described "reduced capacity"; app cadence slowed. Highest abandonment risk among the strong candidates. Verify current staffing before depending on it. [HYPOTHESIS]
  • Zones: content Strong / metadata Strong / network-identity Strong.
  • Fit: offline ❌ · E2E+local keys ✅ · no-server ✅ (untrusted discardable group servers) · keypair + group model ✅ — real multi-party groups that map well onto Circles (its best fit point) · vulnerable ⚠️ (onion-address exchange + Tor latency) · battery ⚠️/❌ (Tor-always, no mesh escape) · refurb ⚠️ (Tor latency on weak CPUs).
  • Why it matters: best group-metadata model + permissive embeddable library. If MPowerUP wants a metadata-resistant Circle layer, libcwtch is the component to study — gated by Cwtch's funding fragility and the no-offline-tier gap.
  • Sources: https://cwtch.im/cwtch.pdf · https://openprivacy.ca/work/cwtch/ · https://git.openprivacy.ca/cwtch.im

Quiet (tryquiet.org)

  • One-liner: Slack/Discord-style team chat with no servers — syncs over Tor + libp2p/IPFS directly between a community's devices.
  • Architectural echo: ⚠️ Runs libp2p-over-Tor with CRDT-style replication — structurally parallel to MPowerUP's own Yjs-CRDT-over-libp2p stack. The closest existing prior-art to MPowerUP's design; worth studying directly even though not adoptable.
  • Status: ❌ Self-described (May 2026) as not audited, "should not be used when privacy and security are critical," missing basic features. GPLv3 + heaviest stack (Tor + IPFS + libp2p) on mobile. Community/team model is a strong Circle analog, but not production-ready for vulnerable users now.
  • Zones: content Strong / metadata Medium-Strong / network-identity Strong.
  • Sources: https://tryquiet.org/ · https://github.com/TryQuiet/quiet/wiki/Quiet-FAQ

Session (Oxen)

  • One-liner: No-phone-number messenger onion-routed over the Oxen Service Node network (not Tor). Best onboarding UX in the branch.
  • Honest strikes (per the no-sycophancy directive):
  • ❌ No forward secrecy today — Session removed PFS; Protocol V2 (re-adding FS + PQ) still under development, expected 2026–2027. A compromised long-term key exposes past intercepted messages.
  • ❌ 2026 IACR paper (eprint 2026/773) reports ~7 vulnerabilities including an Oxen consensus flaw allowing a realistic network takeover plus V1 group-protocol flaws — undermining the anonymity it rests on.
  • ⚠️ Token/blockchain dependency (Oxen/SENT) — conflicts with free-to-vulnerable-users mission.
  • Strengths (real): ✅ best onboarding (no phone number, polished app), ✅ lightest battery in the metadata-resistant set (swarm does store-and-forward, push-like — no self-hosted onion service).
  • Zones: content Medium (no PFS) / metadata Medium-Strong / network-identity Medium (consensus-takeover finding downgrades it).
  • Net read: [HYPOTHESIS] Best UX/battery, but do not present its anonymity as settled — the 2026 attack + missing PFS + token dependency are meaningful strikes for vulnerable users.
  • Sources: https://eprint.iacr.org/2026/773 · https://github.com/oxen-io/session-desktop/issues/2338 · https://en.wikipedia.org/wiki/Session_(software)

OnionShare & Ricochet-Refresh (narrow / wrong-shape)

  • OnionShare — ephemeral file-share / chat over an on-demand onion service. ✅ Lightweight (runs only while sharing), permissive-ish (GPLv3). ❌ Not a persistent messenger. Useful only as an ad-hoc anonymous file/secret-drop primitive, not a platform. Stable 2.6.3 (Feb 2025).
  • Ricochet-Refresh — minimalist anonymous 1:1 over Tor onion services (Cwtch's ancestor). ❌ No groups, no mature Android, no async → fails the Circle requirement and the mobile requirement. Prefer Cwtch on every MPowerUP axis. Maintained but donation-precarious (3.x, June 2026; running a crowdfunding drive).
  • Sources: https://github.com/onionshare/onionshare/releases · https://github.com/blueprint-freespeech/ricochet-refresh

Branch takeaways

  1. Offline-first is the branch's weakness — except Briar. Tor needs the internet; Briar's Bluetooth/Wi-Fi mesh + sneakernet + Mailbox is the only blackout-capable design. If offline-first is truly non-negotiable, Briar's architecture is the one to study/fork.
  2. Strongest metadata-resistant apps with real groups: Cwtch and Briar. Cwtch's untrusted-discardable-group-server is the cleanest Circle analog and ships as a permissive embeddable library (libcwtch) — gated by funding fragility. Briar has groups but a feed-style model and GPLv3.
  3. Battery is a real, not theoretical, cost. Hosting a persistent onion service (Briar-online / Cwtch / Ricochet) keeps the radio awake; Session is lightest (swarm store-and-forward) but you pay with the Oxen dependency. No clean budget-device benchmark exists.
  4. License split favors embedding from the permissive side: Tor / Arti / Cwtch (libcwtch) / Ricochet / i2pd = permissive; Briar / Quiet / OnionShare / Session = GPLv3.
  5. Substrate-reuse path: keep MPowerUP's own app but add Tor's network-identity protection via Arti (client side) — see protocols and Tor as infrastructure.