Skip to content

Candidates — True Peer-to-Peer / Serverless

Validation status: Architecture/license/maintenance facts sourced (2026). All fit-vs-MPowerUP verdicts are [HYPOTHESIS] — none piloted.

Branch summary. Of the non-Tor true-P2P messengers, only Jami is production-grade, actively maintained, with mature mobile — but it exposes IP to peers and is battery-heavy. Berty has the best offline BLE mesh and a permissive license, but self-declares "not hardened — do not use for sensitive data." Tox and SSB carry disqualifiers for vulnerable users (unaudited/alpha crypto + IP exposure; permanent un-deletable logs + abandonment). Matrix-P2P/Pinecone is dormant since 2022 with an unpatched CVE.

Jami (OpenDHT)

  • One-liner: GNU/FSF-backed fully serverless P2P messenger (chat/voice/video) on OpenDHT; formerly "Ring."
  • Architecture: True P2P. OpenDHT (Kademlia DHT) for bootstrap/rendezvous + async distribution; media flows directly peer-to-peer via ICE. Optional name server + DHT proxy (for mobile push) are not in the data path.
  • Identity: Keypair / X.509; Jami ID = public-key fingerprint, generated and stored on-device. Optional username via name server.
  • Encryption: Content E2E with perfect forward secrecy; TLS 1.3 / X.509, SRTP for media.
  • Metadata: No central directory (good), but DHT participation exposes presence/queries to DHT neighbors; no mixing → timing/size correlation possible.
  • Network identity: ⚠️ IP exposed — peers exchange public/local IPs through the DHT to establish the direct link; any connected peer learns your IP. DHT proxy does not hide IP from peers. No Tor.
  • Offline: LAN-offline works (mDNS peer discovery); no Bluetooth/BLE mesh — needs IP connectivity. Limited store-and-forward.
  • Mobile/battery: Mature Android app (cx.ring, F-Droid/Play). ❌ Battery is a known problem — historically needed a persistent foreground connection; UnifiedPush (F-Droid builds) mitigates but doesn't eliminate.
  • License: GPL-3.0-or-later (strong copyleft — embedding the daemon encumbers the host app). OpenDHT also GPL-3.0.
  • Maintenance (2026): Active, well-funded (Savoir-faire Linux + FSF). Lowest abandonment risk in this branch.
  • Zones: content Strong / metadata Medium / network-identity Weak.
  • Fit: offline ⚠️ (LAN only) · E2E+local keys ✅ · no-server ✅ · keypair+groups ✅ (swarm conversations) · vulnerable/budget-Android ⚠️ (IP exposure is a real safety risk) · battery ❌ · refurb ✅.
  • Sources: https://jami.net/ · https://docs.jami.net/en_US/user/jami-distributed-network.html · https://jami.net/jami-and-proxys/ · https://en.wikipedia.org/wiki/Jami_(software)

Berty (Wesh Protocol)

  • One-liner: Offline-first serverless P2P messenger on libp2p with a genuine BLE/Wi-Fi offline-mesh transport.
  • Architecture: True P2P over libp2p; direct transports = Android Nearby / Apple Multipeer / BLE, plus internet transports. No central server.
  • Identity: Keypair created locally; accounts + contacts creatable fully offline, no phone number.
  • Encryption: ⚠️ Wesh Protocol — but project docs state it is "partially implemented," "not yet hardened," and the app "should not yet be used to exchange sensitive data." Exact cipher/PFS undocumented.
  • Metadata / network identity: Strong over BLE/offline (no IP); over internet, libp2p multiaddrs/IPs observable to relays/peers. No Tor.
  • Offline: ✅ Strongest non-Tor offline story — create account, add contacts, message entirely over BLE/Nearby with no internet, peers in radio range.
  • Mobile/battery: Native Android/iOS, active (v2.471.x, mid-2026; BLE stack still stabilizing). ❌ BLE scan/advertise + libp2p persistence is inherently battery-active.
  • License: ✅ Apache-2.0 OR MIT — the only permissive license in this branch; most embeddable/forkable.
  • Maintenance (2026): Active (1,170+ releases) but small team + repeated "not for sensitive data" warnings → moderate abandonment/maturity risk.
  • Zones: content Weak (not hardened) / metadata Medium / network-identity Strong (BLE) / Medium (online).
  • Fit: offline ✅ (best-in-class BLE mesh) · E2E+local keys ⚠️ (not hardened) · no-server ✅ · keypair+groups ✅ · vulnerable/budget-Android ⚠️ (ships with do-not-use-for-sensitive-data warning) · battery ❌ · refurb ✅.
  • Why it matters to MPowerUP: the Wesh/BLE-mesh transport is the single most directly relevant artifact to study for a Z0 offline tier — permissive license, libp2p foundation. Borrow the pattern; do not ship the crypto as-is.
  • Sources: https://berty.tech/docs/protocol/ · https://berty.tech/blog/bluetooth-low-energy · https://github.com/berty/berty

Tox (toxcore) + qTox / aTox

  • One-liner: Fully serverless P2P messaging/voice protocol; reference lib c-toxcore (TokTok).
  • Architecture: True P2P over a global DHT for discovery; direct peer connections after.
  • Identity: Keypair (Curve25519); Tox ID = public key + nospam + checksum, stored locally.
  • Encryption: ⚠️ NaCl/libsodium with PFS, but WireGuard's author flagged "homebrew crypto" + KCI weaknesses; a Noise-handshake redesign has been in progress since ~2023 and toxcore has never completed an independent professional audit. Disqualifying for vulnerable users.
  • Network identity: ❌ IP exposed to contacts (onion routing covers only the discovery phase, not conversation transport).
  • Offline: ❌ Both parties generally must be online; no robust store-and-forward; no BLE mesh.
  • Mobile/license/maintenance: aTox (F-Droid) lags the core; GPL-3.0; maintained but self-labeled "alpha… dangerous security vulnerabilities… not formally audited."
  • Zones: content Medium / metadata Medium / network-identity Weak.
  • Fit: offline ❌ · E2E ⚠️ (unaudited) · no-server ✅ · keypair+groups ⚠️ (fragile groups) · vulnerable ❌ · battery ❌ · refurb ✅. Verdict: reject — alpha crypto + IP exposure.
  • Sources: https://tox.chat/download.html · https://en.wikipedia.org/wiki/Tox_(protocol) · https://github.com/TokTok

Secure Scuttlebutt (SSB) + Manyverse

  • One-liner: Offline-first gossip-based decentralized social protocol (append-only signed logs); Manyverse is the mobile client.
  • Architecture: P2P replication of per-user append-only feeds over Bluetooth/LAN/internet. Optional Pubs/Rooms = public-IP relays.
  • Identity: Keypair (Ed25519 public key = identity), stored locally.
  • Encryption: ⚠️ Public posts are signed but not encrypted; private messages use private-box E2E. No forward secrecy, no deletion — append-only logs are permanent and immutable.
  • Metadata: ❌ Poor — social graph + public posts propagate openly via gossip; permanent un-deletable log is itself a hazard for vulnerable users.
  • Offline: ✅ Excellent — fully local-first DB, syncs over Bluetooth/LAN/internet.
  • Mobile/license/maintenance: Manyverse (se.manyver) is beta; MPL-2.0 (core libs MIT); ⚠️ at risk — lead dev lists it as a "Previously" project; trackers report it won't receive general updates. Single-maintainer bus-factor.
  • Zones: content Weak / metadata Weak / network-identity Weak.
  • Fit: offline ✅ · E2E ⚠️ (DMs only, no PFS/deletion) · no-server ✅ · keypair ✅ / groups ⚠️ · vulnerable ❌ (permanent logs + open graph) · battery ⚠️ (feed bloat) · refurb ⚠️ (storage growth). Verdict: reject for this population — permanent logs + abandonment risk.
  • Sources: https://ssbc.github.io/scuttlebutt-protocol-guide/ · https://github.com/staltz/manyverse · https://nlnet.nl/project/Manyverse/

Matrix P2P / Pinecone

  • One-liner: Experimental fully-P2P Matrix — embedded Dendrite homeserver routed over the Pinecone overlay (incl. BLE mesh).
  • Status: ❌ Dormant / effectively abandoned. Last Pinecone release v0.11.0 (2022-11-17); a known unpatched XSS (GO-2025-3500) against pineconesim. Never productized; running a full homeserver on-device is structurally too heavy for budget phones. The one strong point — Olm/Megolm E2E — is better extracted via matrix-sdk-crypto (see protocols) without the dormant overlay.
  • Verdict: do not adopt. Academic interest only.
  • Sources: https://github.com/matrix-org/pinecone · https://pkg.go.dev/github.com/matrix-org/pinecone

Branch takeaways

  1. Offline-first is where even this branch is thin. Only Berty (alpha) does genuine BLE mesh here; Jami is LAN-only; Tox can't store-and-forward. For a mature Z0 offline tier, Briar (Tor-branch) is the reference, not anything here.
  2. Jami and Berty are the only two worth deeper evaluation — Jami for production maturity (despite IP exposure + battery), Berty for its permissively-licensed BLE-mesh transport (despite not-hardened crypto).
  3. License split: Jami/Tox = GPL-3.0 (copyleft); SSB = MPL/MIT; Berty = Apache/MIT (the embeddable one).
  4. No battery benchmarks exist on ~4 GB Android for any of these — all battery verdicts are structural inference [HYPOTHESIS].