Architecture Taxonomy — the structural shapes¶
Validation status: [HYPOTHESIS] on fit framing; the architectural facts and standards citations are established.
Before comparing apps, fix the vocabulary. The candidates in this survey span six structural shapes, not one. The shape determines where metadata lives, which is the real privacy question — not whether content is encrypted.
The six shapes¶
| # | Shape | Example | Servers in data path? | Servers sync each other? | Identity | Where metadata lives | Authoritative reference |
|---|---|---|---|---|---|---|---|
| 1 | Peer-to-peer | Jami, Briar (local), Tox, Berty | No | N/A | DHT/onion/keypair fingerprint | At the endpoints only (best case) | https://docs.jami.net/ · https://briarproject.org/how-it-works/ |
| 2 | Anonymity-network (onion/garlic/mix) | Tor + Cwtch/Briar-online, I2P, Nym | Relays/mixes (blind) | No | Onion address (keypair) | Hidden from network by routing; timing-correlation caveat | https://www.torproject.org/ · https://nym.com/mixnet |
| 3 | Client–relay | Nostr/Damus | Relays (store/forward) | No (client fans out) | Persistent keypair (npub) | At relays + in the public identifier itself | https://github.com/nostr-protocol/nips |
| 4 | No-persistent-identifier | SimpleX | Relays (per-queue, blind) | No | None (per-connection keys) | Fragmented across per-queue addresses — minimized by design | https://github.com/simplex-chat/simplex-chat |
| 5 | Federated | Matrix, XMPP, ActivityPub | Homeservers/instances | Yes (server-to-server) | user@server account |
At your home server (sees everything) | https://www.w3.org/TR/activitypub/ · https://spec.matrix.org/ |
| 6 | Centralized | conventional baseline | One provider | N/A | Provider account | At the provider (single point) | https://datatracker.ietf.org/doc/html/rfc8446 |
The original MPowerUP research had four shapes. This reconsideration splits two that matter: anonymity-network (2) is broken out from raw P2P because Tor/I2P/Nym change the network-identity axis decisively, and no-persistent-identifier (4) is broken out from client–relay because SimpleX's removal of the identifier is a categorically different privacy property than Nostr's public keypair.
The one distinction worth memorizing¶
The difference between client–relay (3) and federated (5) is whether the servers talk to each other:
- Relays do NOT sync → your client fans out and sees everything; each relay sees only what you send it.
- Federated instances DO sync → your home server does the work and sees everything you do.
That decides where the metadata concentrates — in your own client, or in a server you don't control.
The privacy/reach gradient¶
Top → bottom (shape 1 → 6), privacy and user-sovereignty fall while reach, discovery, and convenience rise. This is the same spectrum as the zones model: P2P + anonymity-network anchor the high-privacy end; client–relay and federated occupy the middle (with different metadata profiles); centralized is the open baseline.
A critical refinement from the Damus/Nostr analysis: this single gradient is too coarse to make decisions on. A real system scores on three independent axes at once. A Tor-routed app and a P2P-DHT app can both be "high privacy" on the gradient yet differ completely on network-identity protection. Collapsing them hides the exact risk that matters. That is why the next note replaces the gradient with a three-axis zone model.
How each shape fares against "no central server" (#3) and "offline-first" (#1)¶
- Shapes 1–2 can satisfy no central server genuinely (relays are blind/optional). Only shape 1 with a local radio transport (Briar/Berty BLE) satisfies strict offline-first; onion-routed shape 2 needs the internet.
- Shapes 3–4 are "no central server" but still need some reachable relay — they do store-and-forward, not internet-free local delivery.
- Shapes 5–6 require always-on infrastructure and fail both #1 and #3 by construction.
MPowerUP's current stack is shape 1 (relay-assisted P2P) — direct WebRTC between devices with a content-blind signaling relay. The reconsideration question is whether to stay there, move toward shape 2 (add Tor for network-identity), or borrow a true local-mesh tier (Briar-style) to make #1 real.
Licensing caution (carried from the original research)¶
Shape matters less than license for reuse. Strong-copyleft cores (Jami/Tox/Briar = GPLv3; SimpleX/Matrix-server = AGPLv3) constrain what they can be bundled into. Permissive cores (Cwtch/libcwtch, Arti, Iroh, OpenMLS, nostr-tools, Yjs = MIT/Apache/BSD) are friendlier to embedding under MPowerUP without copyleft propagation. The per-candidate notes flag this on every entry; the decision matrix collects it in one column.