Skip to content

Reconsideration Verdict — build, adopt, or hybrid?

Validation status: [HYPOTHESIS] — this is a reasoned recommendation from the 2026 survey, not a validated decision or a pilot result. It is explicitly written to be disconfirmable: the Known Unknowns below could overturn it.

The question, restated: can MPowerUP achieve its goals using existing open-source apps and systems instead of building everything itself?

The honest answer

No existing app replaces MPowerUP without sacrificing at least one non-negotiable — but several should supply components to, inform, or interoperate with it. The recommendation is a hybrid, not "build everything" and not "adopt a single app."

This is the no-sycophancy reading: it would be easier to either (a) bless the existing custom build as obviously correct, or (b) declare "just use Briar/SimpleX and stop building." Both are wrong. The evidence supports a narrower, more uncomfortable middle.

Why not "adopt a single existing app"

The binding constraint is offline-first interpreted strictly (works device-to-device with no internet at all). The field is nearly empty here: - Briar is the only mature app that qualifies — but it's GPLv3 (copyleft), its groups are feed-style (not a tight Circle admin model with facilitator/member/observer roles), and it's battery-heavy. - SimpleX has the best identity/metadata model and a small-group shape that fits Circles — but it's AGPLv3, Haskell-cored (hard to embed in React Native), and has no local mesh. - Cwtch has the best group-metadata design and a permissive embeddable library — but it's Tor-only (no offline tier), the heaviest on battery, and funding-fragile.

No single app clears all seven. Adopting one means giving up a non-negotiable, and for vulnerable users that is a higher-bar decision than convenience.

Why not "keep building everything from scratch"

The survey surfaced hardened, permissively-licensed components that MPowerUP would be reinventing — and reinventing crypto/transport for vulnerable users is its own epistemic risk. The js-libp2p failure also shows the team has already hit the integration wall that better-resourced primitives (Iroh, Arti, OpenMLS) are designed to avoid.

Therefore: hybrid

Keep building MPowerUP's own app on its RN-proven core (Yjs / WebRTC / did:key / WatermelonDB), because that core is what satisfies the Circle model + offline-first ambition that no off-the-shelf app delivers whole — but adopt vetted components and borrow proven patterns instead of hand-rolling the hard parts, and interoperate with / refer to the best existing apps where they serve users today.

The hybrid, concretely

Keep (RN-proven, working — do not migrate a functioning layer for vulnerable users)

  • did:key identity · Yjs per-Circle sync · WebRTC transport (as baseline) · WatermelonDB storage.

Adopt / spike (highest value first)

  1. Arti (client-side Tor) → add the network-identity (IP) axis the current stack lacks. Route MPowerUP's relay/sync traffic over Tor as an opt-in high-privacy mode (Z1→stronger). Don't host onion services from Arti yet (not as hardened as C-Tor).
  2. Iroh → evaluate as the transport (QUIC + hole-punching + relay-fallback) replacing bespoke WebRTC+relay glue. Gate: current RN Kotlin/Swift binding maturity — spike before committing.
  3. MLS / OpenMLS → evaluate as the group-encryption upgrade over the per-Circle shared-symmetric-key model (gains forward secrecy + post-compromise security — real for users whose devices may be seized). Gate: decentralized-delivery integration, not the crypto.
  4. Verifiable Credentials (SD-JWT-VC) on existing did:key → Phase 4 trust attestations.

Borrow the pattern (don't take the code)

  • Briar's BLE / Wi-Fi-Direct mesh → the reference design for MPowerUP's missing Z0 offline-mesh tier, implementable natively on RN without depending on Briar's GPLv3 code.
  • Berty's Wesh BLE transport (permissive) → the closest existing implementation to study for that tier.
  • SimpleX's no-persistent-identifier model → a design exemplar for minimizing metadata in the Circle layer.
  • Cwtch's untrusted-discardable group server → the cleanest group-metadata pattern to study (via permissive libcwtch).
  • Quiet's libp2p-over-Tor + CRDT → closest prior-art to MPowerUP's own design; study its architecture directly.

Interoperate with / refer to (serve users today)

  • Briar (Android) and SimpleX are honest interim referrals for users who need offline-resilient or maximally-metadata-private messaging now, before MPowerUP's own tiers ship. Also the recommended privacy messengers in the Second Boot toolbox.

Reject (with reasons)

  • libsignal (AGPL + group-shape mismatch) · go-libp2p/gomobile (unmaintained binding; Iroh dominates) · Tox / SSB / Pinecone (alpha-or-abandoned, unsafe for vulnerable users) · ActivityPub (no E2E) · Ditto (proprietary) · Session as a trust anchor (no PFS + 2026 Oxen consensus attack).

What this changes vs. the current build

Layer Today Reconsidered direction
Identity did:key Keep; add VCs (Phase 4)
Group encryption TweetNaCl + shared Circle key Spike MLS (FS + PCS)
Transport relay-assisted WebRTC Keep baseline; spike Iroh; add Arti/Tor opt-in for network-identity
Sync Yjs CRDT Keep; read the Cinapse counter-evidence first
Offline tier LAN/relay only Add a Z0 BLE/Wi-Fi-Direct mesh (Briar/Berty pattern) — the biggest functional gap
Privacy zones implicit Make the 3-axis zones model explicit in UI + code

The single most important new capability is the Z0 offline-mesh tier — it's the one non-negotiable (#1, strict offline-first) that neither the current build nor any single existing app fully delivers, and it's where MPowerUP's mission is most differentiated.

Known Unknowns that could overturn this verdict

  1. Definition of "offline-first." If it means "survives intermittent internet" (not "no internet at all"), then SimpleX/Delta Chat re-enter as near-complete solutions and the build-your-own case weakens substantially. This definition must be resolved first — it is the hinge of the whole verdict.
  2. Copyleft tolerance. If MPowerUP will accept AGPLv3, SimpleX becomes adoptable as a component, not just an exemplar.
  3. Battery reality. Every Tor-always / mesh-always recommendation rests on unmeasured battery claims. A measured pilot on a ~4 GB refurb Android is required before committing to Arti-always or a mesh-always tier.
  4. The CRDT premise. The Cinapse "moving away from CRDTs" report is real disconfirming evidence; not yet weighed against MPowerUP's small-Circle scale.
  5. Cwtch / small-project funding health. Several "study this" recommendations point at projects (Cwtch, Berty, Earthstar) with bus-factor/funding risk — verify before depending on any.
  1. Resolve the offline-first definition (team decision) — unblocks everything else.
  2. Battery pilot: measure Tor-over-Arti and a BLE-mesh prototype on a representative refurb device.
  3. Three time-boxed spikes: Iroh RN binding · MLS FFI + decentralized delivery · a BLE/Wi-Fi-Direct Z0 mesh prototype.
  4. Read the Cinapse CRDT report and decide whether it changes the sync premise.
  5. Author the Second Boot privacy toolbox + Tor relay lab in that repo (see Tor as infrastructure).
  6. Promote a future ADR in mpowerup/docs/decisions/ once a spike produces evidence — this vault survey is the input, not the decision record.

This verdict is the input to a decision, not the decision. Per the Epistemic Honesty directive, it should not be cited to a funder as a settled architecture — it is a [HYPOTHESIS]-grade recommendation awaiting the spikes and the offline-first definition above.