Communication Architecture Reconsideration¶

Validation status: [HYPOTHESIS] — This is a survey-and-fit analysis, not a validated decision. Every "fit" and "could replace" judgment is a working assessment against MPowerUP's stated goals; none has been piloted against real MPowerUP users. Architecture/protocol facts are sourced (2026); fit verdicts are [HYPOTHESIS] unless marked otherwise.

Scope. A full reconsideration of MPowerUP's communication and networking stack. The driving question, in the team's words: can we achieve our goals using existing open-source apps and systems instead of building everything ourselves? This survey inventories the open-source candidates across architecture, privacy, security, and autonomy models; defines a device-level "zones" model for how users actually interact; scores every candidate against MPowerUP's non-negotiables; and renders an honest go/no-go on the build-vs-adopt question.

Why it exists. The earlier MPowerUP comms research (Jami + Nostr + Mastodon + "security zones") predates the current shipped stack (Yjs CRDT + relay-WebRTC + did:key + WatermelonDB, Phase 1 complete). This document re-opens that question with current 2026 evidence rather than assuming the existing build is correct or that an off-the-shelf app could replace it.

How to read this survey¶

Note	What it gives you
Architecture taxonomy	The six structural shapes (P2P, Tor/anonymity-network, client–relay, no-identifier, federated, centralized) and the one distinction that decides where metadata lives
Zones model	The device-level interaction model: every user moves through privacy zones, and a zone is three independent axes, not one label
Candidates — P2P / serverless	Jami, Tox, Berty, Secure Scuttlebutt, Matrix-P2P
Candidates — Tor-native / metadata-resistant	Tor substrate (Arti, Orbot, Snowflake), I2P, Nym, Briar, Cwtch, Quiet, OnionShare, Session, Ricochet-Refresh
Candidates — client–relay / no-identifier	SimpleX, Nostr (Damus/Amethyst), NIP-EE/Marmot (MLS-over-Nostr)
Candidates — federated / server-based	Matrix, XMPP, ActivityPub family, Delta Chat
Protocols & primitives	MLS, Signal/libsignal, did:key/VCs, Iroh, Veilid, Hypercore, Yjs/Automerge/Loro, Meshtastic, Reticulum — the reusable building blocks
Tor as infrastructure	Tor as an internet tool, the Ubuntu toolbox, and running a Tor relay as a learning + contribution (Second Boot tie-in)
Reconsideration verdict	The build-vs-adopt answer, the hybrid recommendation, and the spikes to run
Decision matrix	Every candidate scored against the 7 non-negotiables + 3 zone axes in one table
Tool tracker	Live evaluation tracker (status / Private-Autonomous-Secure axes / score), maintained by the `tool-eval` skill
Source research (provenance)	The original seed notes (verbatim) this reconsideration supersedes — incl. the 4-architecture diagram + graph-DB survey

The bar: MPowerUP's seven non-negotiables¶

Pulled from the MPowerUP docs (CLAUDE.md, architecture.md, local-first-strategy.md), not invented. Every candidate is scored against these.

Offline-first — works with no internet, cellular, or grid power.
E2E encryption with keys held only in on-device secure storage.
No central server — content-blind relay at most; self-hostable; functions without it.
Trusted Circles — keypair (not account) identity; explicit roles/permissions; a real private-group model.
Vulnerable-population safety — low digital literacy, budget Android (~4 GB RAM).
Battery-conscious / off-grid — no polling, no persistent sockets, no continuous GPS.
Sustainability — runs on refurbished hardware (Second Boot pipeline).

Executive summary — the load-bearing findings¶

No single existing app satisfies all seven. The binding constraint is #1 offline-first interpreted strictly (works device-to-device with no internet at all). Almost nothing in the field does this. Briar is the only mature candidate with genuine Bluetooth/Wi-Fi mesh + sneakernet; Berty also does BLE mesh but self-declares "not hardened — do not use for sensitive data." Every Tor app, every relay app, every federated system goes dark in a connectivity blackout.
"E2E encrypted" is not the bar — metadata is. The clearest lesson: Nostr DMs can be perfectly content-encrypted yet leak who-talks-to-whom because identity is a persistent public key. A zone must be scored on content confidentiality, metadata exposure, and network-identity (IP) separately. See zones-model.
The three strongest existing apps each fail a different non-negotiable:
Briar — best offline-first + audited crypto + Android-native, but GPLv3 (copyleft), feed-style groups (not a tight Circle admin model), and persistent-service battery cost.
SimpleX — best metadata resistance (no persistent identifiers at all) + small-group model that maps onto Circles, but AGPLv3 + Haskell core (hard to embed in React Native) + no local mesh (relay store-and-forward only).
Cwtch — best metadata-resistant group model + permissive libcwtch (embeddable), but Tor-only (no offline mesh), heaviest battery, and fragile single-nonprofit funding.
The highest-value move is "reuse components, not adopt whole apps." Several projects expose hardened, permissively-licensed building blocks worth embedding under MPowerUP's own app: matrix-sdk-crypto (network-free Olm/Megolm group E2E), Arti (embeddable Tor for network-identity protection), Iroh (QUIC transport with hole-punching + relay — the best-resourced libp2p alternative), OpenMLS (RFC 9420 group crypto with post-compromise security), and nostr-tools (if a public broadcast layer is ever wanted).
The recurring failure mode is integration, not cryptography. js-libp2p didn't fail on crypto — it crashed on React Native. The pattern repeats: the protocol is rarely the blocker; the RN/mobile binding maturity and battery profile are. This favors the Rust-core + native-FFI path (Iroh, Arti, OpenMLS) over forcing implementations through RN's JS runtime.
The honest disconfirming evidence: a 2026 case study (Cinapse) documents a team moving away from CRDTs at scale (document bloat, tombstone/metadata overhead). This is the strongest counter-argument to MPowerUP's own Yjs-centric premise and is logged as a Known Unknown — see protocols-and-primitives.

Bottom line (full reasoning in the verdict): [HYPOTHESIS] No existing app replaces MPowerUP without sacrificing a non-negotiable — but several should inform, supply components to, or interoperate with it. The recommendation is a hybrid: keep building MPowerUP's own app on its RN-proven core; adopt Tor/Arti for the network-identity axis; borrow Briar's BLE-mesh pattern for a true offline tier; evaluate MLS for the group-crypto upgrade; and treat Briar / SimpleX as honest interim referrals for users who need them today.

Known Unknowns¶

Question	Why it matters
Does "offline-first" mean survives intermittent internet or works with no internet at all (true mesh)?	This single definition decides whether Delta Chat/SimpleX qualify or only Briar/Berty do. The whole verdict hinges on it.
Is MPowerUP willing to take on AGPLv3 (SimpleX) or GPLv3 (Briar) copyleft?	Determines whether the two strongest apps are adoptable at all, vs. permissive components (Cwtch/libcwtch, Arti, Iroh, OpenMLS, matrix-sdk-crypto).
What is the real battery cost of persistent Tor / BLE-mesh on a ~4 GB refurb Android with an aged battery?	No clean 2026 benchmark exists; all battery claims here are structural inference. A measured pilot is required before any Tor-always or mesh-always design.
Is the CRDT premise itself sound at MPowerUP's scale?	The Cinapse report is real disconfirming evidence; not yet weighed against MPowerUP's small-Circle scale.
Cwtch maintenance health in 2026 (Open Privacy funding/staffing).	Cwtch is the best group-metadata design but reportedly under-resourced; verify before depending on it.

Companion documents already in the vault: [[Why do you need peer 2 peer networking?]] · red-team-mpowerup.md (privacy attack surface) · [[MPowerUP Guardian AI]] · Tool Integrations. Project-side references: mpowerup/docs/architecture.md, mpowerup/docs/decisions/0001-p2p-transport.md, mpowerup/docs/local-first-strategy.md.