Skip to content

Candidates — Federated / Server-Based

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

Bottom line up front. All four families here are server-mediated: an always-on homeserver/instance relays, stores, and synchronizes messages. This conflicts directly with MPowerUP's offline-first / no-central-server / battery non-negotiables — they survive a user being temporarily offline (store-and-forward), not the absence of infrastructure. They are surveyed to know what we'd be giving up, and to extract two genuinely reusable artifacts. Delta Chat is the one real outlier.

Matrix (Synapse / Dendrite / conduwuit + Element / FluffyChat)

  • Architecture: Federated — homeservers replicate room state (event DAG) to every server with a participant. Your homeserver stores all your room history (content opaque if encrypted, but events/timing/membership are not).
  • Identity: ❌ @user:homeserver — account bound to a server; not a self-sovereign keypair. Account portability unsolved.
  • Encryption: ✅ Olm/Megolm — the strongest production group-E2E in this branch. Not on by default historically (improving); device-verification UX is hard for low-literacy users.
  • Metadata: ❌ High — homeserver sees membership/timing/who-you-talk-to/presence; federation traffic is largely plaintext at the protocol level → traffic analysis even with encrypted content. (Element sells a closed-source Secure Border Gateway to mitigate this — i.e. the leakage is real.)
  • Offline / battery: ❌ Store-and-forward via homeserver only; no operation without a server. P2P-Matrix is an experiment (Element planned "pragmatic P2P work in 2026"; store-and-forward routing for offline nodes unsolved) — not a foundation. Persistent sync / FCM push dependency.
  • License: Servers (Synapse/Dendrite) moved to AGPL-3.0 (2023); conduwuit is permissive Rust; Element clients largely AGPL.
  • Maintenance (2026): Active, well-funded; ⚠️ Foundation can't resource Dendrite (Element does); conduwuit actively maintained.
  • ⭐ Reusable artifact: matrix-rust-sdk → matrix-sdk-crypto is a standalone, network-free Olm/Megolm E2E state machine (Rust + Kotlin/Swift/JS bindings). Directly reusable as a hardened group-E2E component on top of MPowerUP's own P2P transport, without taking Matrix federation. The single most valuable reusable piece in this branch.
  • Zones: content Strong / metadata Weak / network-identity Weak.
  • Fit: offline ❌ · E2E ⚠️ (keys local but server mediates all) · no-server ❌ · keypair-identity ❌ (@user:server; rooms ≠ Circle trust model) · vulnerable ⚠️ (verification UX) · battery ❌ · refurb ✅ server-side (conduwuit/Dendrite on Pi-class — but that reintroduces a server).
  • Sources: https://spec.matrix.org/ · https://github.com/matrix-org/matrix-rust-sdk · https://arewep2pyet.com/ · https://wire.com/en/blog/matrix-not-safe-eu-data-privacy

XMPP (Prosody / ejabberd + Conversations / Snikket, OMEMO)

  • Architecture: Federated — servers route stanzas between domains (S2S). Each user has an account on one server storing roster/offline messages.
  • Identity: ❌ user@domain JID — server-bound account, not a keypair.
  • Encryption: OMEMO (XEP-0384, Signal-derived) for 1:1 — mature. ⚠️ Group (MUC) OMEMO still experimental in 2026; E2E is opt-in.
  • Metadata / network identity: ❌ Home server sees roster/presence/timing/recipients; S2S exposes routing metadata + IPs.
  • Offline: ❌ Store-and-forward via server (MAM, offline storage); no operation without a server, no P2P fallback.
  • Mobile / battery: ✅ Best-in-branch for budget Android — Conversations is lightweight, mature, active (2.19.x, 2026); Snikket bundles it for easy self-hosting. ⚠️ Battery is comparatively good for a federated system (XEP-0352 CSI, XEP-0357 push, XEP-0280 carbons) but still connection/push-dependent.
  • License: Conversations GPL-3.0; Prosody MIT; ejabberd GPL-2.0.
  • Maintenance (2026): Active ecosystem (Prosody 13.0.6, ejabberd 26.04); smaller funding than Matrix.
  • Zones: content Strong (1:1) / Medium (groups) / metadata Weak / network-identity Weak.
  • Fit: offline ❌ · E2E ⚠️ · no-server ❌ · keypair-identity ❌ · vulnerable ✅ (Conversations genuinely good on cheap Android) · battery ⚠️ · refurb ✅ (Prosody on Pi-class).
  • Sources: https://xmpp.org/extensions/xep-0384.html · https://wiki.xmpp.org/web/Tech_pages/OMEMO/MUC · https://en.wikipedia.org/wiki/Conversations_(software)

ActivityPub family (Mastodon / Akkoma / Sharkey / GoToSocial)

  • Architecture: Federated public social networking (the Fediverse) — instances exchange public activities S2S. Each user has an admin-controlled account on an instance.
  • Encryption: ❌ No content E2E anywhere in the family. DMs are limited-audience posts; sending and receiving instance admins read them plaintext. Categorical disqualifier for private mutual-aid messaging.
  • Metadata: ❌ Very high by design — it's a publishing protocol; "private" is a visibility setting, not cryptography.
  • License/maintenance: Mostly AGPL-3.0; very active.
  • ⭐ Narrow relevance: GoToSocial is a single-binary, SQLite, Raspberry-Pi-class ActivityPub server — a clean reference for "self-hostable on refurb hardware" (Second Boot), but it provides no private E2E messaging.
  • Zones: content Weak / metadata Weak / network-identity Weak.
  • Verdict: ❌ Categorically wrong tool — public-social, not private messaging. Survey only; relevant solely as a future Z3 open-broadcast option and a refurb-server reference.
  • Sources: https://www.w3.org/TR/activitypub/ · https://codeberg.org/superseriousbusiness/gotosocial · https://en.wikipedia.org/wiki/Mastodon_(social_network)

Delta Chat ⭐ (the interesting outlier)

  • One-liner: A messenger that uses commodity email (IMAP/SMTP) as transport and "has no servers of its own" — chats are encrypted emails; any mailbox or a minimal "chatmail" relay is the infrastructure.
  • Architecture: ✅ No proprietary infrastructure. E2E-encrypted emails over standard IMAP/SMTP; transport = any mail provider or a purpose-built chatmail relay. 2026 added multi-path delivery (multiple relays, auto-failover if one is blocked) → censorship-resilience without a single point of control.
  • Identity: ⚠️ An email address is the addressable identity, but the encryption identity is an on-device PGP keypair; chatmail relays can be created disposably. More portable than Matrix/XMPP JIDs, but not did:key.
  • Encryption: ✅ E2E by default including groups (Autocrypt/OpenPGP). Autocrypt v2 (rolling out 2026) adds forward secrecy + post-quantum. The only one in this branch E2E-by-default including groups, on commodity infra.
  • Metadata: ✅ Lowest in this branch — with 2.48+/Header Protection (RFC 9788) "a chat message reveals close to zero metadata to servers" (Subject/References encrypted, Date randomized). ⚠️ The mail relay still sees the From/To envelope (who-mails-whom) unless mitigated.
  • Offline: ⚠️ The most interesting partial fit. Compose offline → queues → sends on reconnect; but it still needs a reachable mail server to deliver — NO device-to-device/local-mesh path. It removes the need for new infrastructure, not the need for internet + a mailbox.
  • Mobile / battery: ✅ Native Android, budget-viable; battery = email-client-class (IMAP IDLE / poll), acceptable.
  • License: ✅ Core deltachat-core-rust is MPL-2.0 (favorable for embedding); apps GPL.
  • Maintenance (2026): ✅ Active, NLnet/EU-funded lineage; shipping major releases (2.48+, zero-metadata, native A/V calls).
  • Zones: content Strong / metadata Medium→Strong / network-identity Medium.
  • Fit: offline ⚠️ (no new infra, survives intermittent internet, but needs a mail server; no local/off-grid) · E2E+local keys ✅ · no-server ⚠️ (no central server + multi-relay failover, but a relay is required) · keypair ⚠️ / groups ⚠️ (email-address identity; groups ≠ Circle model out of the box) · vulnerable ✅ (designed for at-risk users, simple UX) · battery ⚠️ · refurb ✅ (chatmail relay self-hostable on Pi-class → Second Boot).
  • Net read: [HYPOTHESIS] The closest philosophical cousin — it proves a "no-new-infrastructure, E2E-by-default, censorship-resilient, near-zero-metadata" messenger is viable on commodity rails. Its load-bearing limitation vs MPowerUP: it cannot do server-less local/off-grid delivery. Whether it qualifies as "offline-first" depends entirely on the Known Unknown about what offline-first means.
  • Sources: https://delta.chat/en/2026-03-31-zero · https://delta.chat/en/help · deltachat-core-rust (MPL-2.0)

Branch takeaways

  1. Shared disqualifier: Matrix / XMPP / ActivityPub make an always-on server mandatory with no operation without infrastructure — the precise opposite of MPowerUP's premise. None can be the messaging foundation without abandoning non-negotiable #3.
  2. ActivityPub is out on encryption grounds alone (no E2E DMs).
  3. Two reusable artifacts to extract, not adopt wholesale: matrix-sdk-crypto (network-free Olm/Megolm — the prize) and deltachat-core-rust (MPL-2.0 engine, tied to email transport).
  4. Delta Chat deserves a deeper look as the no-new-infrastructure exemplar — and as an honest interim option for intermittent-connectivity users.
  5. Refurb-server angle (Second Boot): conduwuit, Prosody, GoToSocial, and Delta Chat chatmail relays all run on Pi-class hardware — relevant only if the architecture accepts an optional community relay, not a required dependency.