Skip to content

Protocols, Primitives & Sync Engines — the reusable building blocks

Validation status: Standards/maturity facts sourced (2026). "Adopt / watch / reject" recommendations are [HYPOTHESIS] — none run on-device by BNI yet.

These are building blocks, not whole apps — the layer where the reconsideration is most actionable, because the answer to "build vs adopt" is usually "build the app, adopt the primitive." MPowerUP today = Yjs CRDT (per-Circle doc) + TweetNaCl + did:key (Ed25519) + WatermelonDB/SQLite + relay-assisted WebRTC (js-libp2p was rejected — event-target-shim crashes on React Native 0.81).

The recurring lens — the libp2p lesson: a primitive can be cryptographically excellent and still be unshippable to vulnerable users on budget Android if the RN/mobile binding is immature. The crypto is rarely the blocker; the binding maturity and battery profile are. This favors the Rust-core + native-FFI path (Iroh, Arti, OpenMLS) over forcing JS implementations through RN's runtime.

Encryption / group-messaging protocols

MLS (RFC 9420) / OpenMLS — evaluate now

  • Maps to: MPowerUP's encryption layer — specifically per-Circle group key management (today: TweetNaCl + one shared symmetric key).
  • Maturity: RFC 9420 published IETF standard; OpenMLS actively released (0.7.2, Feb 2026), interop-tested vs Cisco MLS++ and AWS mls-rs. Most standards-mature option in this report.
  • The real engineering trade vs the current shared-key model: MPowerUP's shared Circle key gives FS only with an added ratchet and is very hard to give Post-Compromise Security — extract one member's key and you read the group indefinitely; healing scales ~O(n²). MLS TreeKEM gives forward secrecy + PCS (the group self-heals after a member updates) with ~logarithmic key updates. Cost: much more implementation complexity (epochs/commits/proposals/welcome), and a harder fit for fully-decentralized delivery — MLS assumes an ordered Delivery Service; running it P2P is active research (phnx.im "Making MLS more decentralized").
  • RN viability: Rust → UniFFI/C-FFI native module (same well-trodden path as Iroh/libsignal). No production pure-JS/WASM MLS for RN as of mid-2026.
  • License: ✅ MIT/Apache (OpenMLS) — major advantage over libsignal's AGPL.
  • Recommendation: Watch → pilot-spike. Adopt the security model (PCS genuinely matters for users whose devices may be seized/compromised); prototype the FFI + decentralized-delivery integration before committing — the delivery gap, not the crypto, is the risk.
  • Sources: https://www.rfc-editor.org/info/rfc9420/ · https://github.com/openmls/openmls · https://github.com/awslabs/mls-rs · https://blog.phnx.im/making-mls-more-decentralized/

Signal Protocol / libsignal — reject as dependency, borrow ideas

  • Gold-standard 1:1 (Double Ratchet + PQXDH). ✅ Superior for pairwise channels. ❌ AGPL-3.0-only (decisive blocker — would AGPL-encumber MPowerUP and downstream redistribution incl. Second Boot preloads). ❌ Group-shape mismatch: Signal's group model is "sender keys" — the same weak-PCS shape we're trying to leave. No official RN binding.
  • Recommendation: Reject the code; borrow the ideas (Double Ratchet for any future 1:1; PQXDH as the post-quantum bar). For groups, MLS is the better target.
  • Sources: https://github.com/signalapp/libsignal · https://signal.org/docs/

Identity

did:key + DIDComm v2 + Verifiable Credentials — keep did:key; adopt VCs (Phase 4); reject DIDComm

  • Maps to: identity layer (MPowerUP already uses did:key) + Phase 4 verifiable attestations.
  • Maturity: DID Core v1.1 at W3C Candidate Recommendation (Mar 2026); VC Data Model v2.0 = W3C Recommendation (May 2025). did:key is just Ed25519 key handling — zero porting risk (MPowerUP already does it via TweetNaCl).
  • Recommendation: Keep did:key (no change). For Phase 4 trust attestations ("verified by partner org"), adopt VCs — prefer SD-JWT-VC (lighter/more mobile-friendly than JSON-LD/BBS), layering cleanly on existing did:key. Reject DIDComm v2 as transport — MPowerUP's CRDT-over-relay already covers messaging; DIDComm adds weight without clear benefit.
  • Sources: https://www.w3.org/TR/did-1.1/ · https://www.w3.org/TR/vc-data-model-2.0/

P2P frameworks / transports (alternatives to libp2p-on-RN)

Iroh (Rust QUIC P2P) — highest-value spike

  • Maps to: transport — exactly MPowerUP's "relay-assisted WebRTC" problem (direct connectivity + NAT hole-punching + relay fallback), but as a maintained library instead of hand-rolled WebRTC+relay glue.
  • Maturity: Strongest momentum here — v1.0.0-rc.1 (May 2026); team (n0) reports production use at 200k concurrent connections / millions of devices.
  • RN viability: ✅ Officially supports Android/iOS via FFI — the opposite of the libp2p-on-RN failure (ship a native binary the JS layer calls, don't force JS through event-target-shim). ⚠️ You still maintain the RN native-module bridge; verify current Kotlin-binding maturity before committing [HYPOTHESIS].
  • vs WebRTC: WebRTC wins for a future web build (Phase 5, native in browsers); Iroh wins on integrated hole-punch+relay+encryption for budget-Android-first. ✅ Apache/MIT.
  • Recommendation: Watch / pilot-spike now — best-positioned libp2p alternative; the only gate is RN-binding maturity. Keep WebRTC as the baseline until a spike proves a clear win.
  • Sources: https://www.iroh.computer/blog/iroh-1-0-0-rc-0 · https://crates.io/crates/iroh

Arti (embedded Tor) — see Tor as infrastructure

  • The path to add network-identity (IP) protection to MPowerUP's own app without adopting a whole Tor app. ✅ MIT/Apache, embeddable crate. ⚠️ Client side production-ready; onion-service hosting not yet as secure as C-Tor — route out over it, don't host from it yet.

Veilid (Cult of the Dead Cow) — watch, do not adopt

  • Privacy-first Rust P2P (routed overlay + DHT). Best privacy philosophy, but ❌ demo-grade (VeilidChat self-describes as a tech demo) and ❌ Flutter-first, no RN binding. Heavier/chattier than relay+direct. MPL-2.0. The libp2p lesson in spirit. Watch.
  • Sources: https://veilid.com/ · https://gitlab.com/veilid/veilidchat

Hypercore / Holepunch / Pear — watch (study Keet)

  • Append-only-log P2P on the Bare runtime. ⭐ Keet Mobile ships with a 100% React-Native UI over Bare — the only shipping consumer mobile app here whose UI is literally RN (proof RN+P2P can ship). ❌ But adoption means embracing Bare as your JS runtime — conflicts with MPowerUP's Expo 54/Hermes foundation; a re-platform, not a swap. Apache-2.0, Tether-funded. Watch / study the architecture.
  • Sources: https://github.com/holepunchto · https://blog.mauve.moe/posts/hyper-react-native

go-libp2p via gomobile — reject (Iroh dominates)

  • Would deliver libp2p on RN where js-libp2p couldn't (native Go binary + FFI), ❌ but the mobile binding is experimental/archived (gomobile-ipfs archived) and running a full libp2p node is heavy. Moves the risk from "JS shim crashes" to "you own an unmaintained bridge." MIT. Reject in favor of Iroh.
  • Sources: https://github.com/libp2p/go-libp2p · https://github.com/ipfs-shipyard/gomobile-ipfs (archived)

Local-first sync engines (alternatives/peers to Yjs)

Engine Verdict Why
Yjs (current) ✅ Keep RN-proven, ~920k weekly npm, MIT, lightest; SQLite-persistence pattern solved. Nothing below clears the bar to migrate a working layer for vulnerable users.
Automerge / automerge-repo Watch MIT; now supports RN via WASM; built-in change history/attribution (could matter for help-request audit trail). Adopt only if Phase 2+ needs version history. Heavier WASM init than Yjs.
Loro Watch MIT; best benchmark perf + smallest encoded size (a real battery/sustainability win at scale) + movable trees. ❌ Young, no proven RN production track record; WASM cold-start its weakest dimension.
Ditto Reject for core Production-grade multi-transport offline mesh (BLE/LAN/P2P) — directly relevant — but proprietary/commercial. Note as a reference architecture, not a dependency.
Willow / Earthstar 11 Watch (don't adopt) Best philosophical fit — capability system = native Circle permissions, partial sync = battery-friendly, private-set-intersection = metadata privacy. ❌ Alpha, TS-only-proven, donation-funded. Too early for vulnerable users.

⚠️ Cross-cutting disconfirming evidence on ALL CRDTs (incl. Yjs): a 2026 case (Cinapse) documents a team moving away from CRDTs for sync due to document-size/memory/tombstone overhead at scale. The strongest counter-argument to MPowerUP's whole sync premise. It does not by itself justify abandoning a working Yjs layer (MPowerUP's per-Circle scale is small), but it is a Known Unknown to read before doubling down. Source: https://powersync.com/blog/why-cinapse-moved-away-from-crdts-for-sync

Off-grid / mesh (sustainability + off-grid directive)

Meshtastic (LoRa) — watch / pilot for off-grid

  • Truly infrastructure-free km-scale comms over cheap LoRa radios — directly serves the off-grid/grid-resilient directive and houseless/disaster-adjacent users. Most mature consumer LoRa-mesh ecosystem; polished Android app; very low power (the radio is a separate device with its own battery).
  • Integration: talk to a Meshtastic node over BLE from RN (react-native-ble-plx) — don't re-implement LoRa. ⚠️ Requires external LoRa hardware per user (cost/logistics — a natural Second Boot build/refurb artifact). GPL-3.0 firmware (fine as a separate BLE device).
  • Complementary, not a replacement: MPowerUP's CRDT/encryption would ride over LoRa's tiny bandwidth (needs aggressive delta compression / store-and-forward). The clearest expression of the off-grid directive in the survey.
  • Sources: https://meshtastic.org/docs/configuration/radio/power/ · https://meshtastic.org/docs/software/android/usage/

Reticulum (RNS) / Sideband — watch

Briar's BLE mesh — reject as dependency, mine the pattern

  • Proves BLE/Wi-Fi-Direct local mesh works for at-risk users without LoRa hardware. ❌ Android-native monolith, no reusable RN mesh component. The lesson MPowerUP can borrow: BLE/Wi-Fi-Direct local mesh is the cheapest Z0 off-grid tier, implementable natively on RN — without depending on Briar's GPLv3 code. See candidates-tor-native.

Synthesis — what to keep / spike / watch / reject

  • Keep now (RN-proven, working): did:key, Yjs, WebRTC. Nothing clears the bar to migrate a functioning layer for vulnerable users.
  • Highest-value spikes (in order): (1) Iroh — transport replacement, best-resourced libp2p alternative, gate = RN binding maturity. (2) MLS/OpenMLS — group-crypto upgrade (PCS), gate = decentralized-delivery integration, not the crypto. (3) Arti (client side) — add the network-identity axis. (4) VCs (SD-JWT-VC) — Phase 4 identity.
  • Watch, don't ship (alpha for vulnerable users): Veilid (Flutter, demo), Willow/Earthstar (alpha), Loro (unproven RN), Reticulum (Python/bus-factor), Hypercore/Bare (re-platform), Meshtastic (off-grid pilot, needs hardware).
  • Reject: libsignal (AGPL + group mismatch), go-libp2p/gomobile (unmaintained binding; Iroh dominates), Ditto (proprietary), Briar code (not a library — borrow the BLE-mesh pattern instead).
  • Biggest Known Unknown: the Cinapse "moving away from CRDTs" report — read deliberately before further CRDT commitment.