The Zones Model — how users actually interact on a device¶
Validation status: [HYPOTHESIS] — a design model, not a validated UX. The three-axis decomposition is well-grounded in the candidate evidence; the per-device interaction framing is a proposal to be pilot-tested.
The team's framing: consider zones as all users interact in these ways on devices. A real person doesn't live in one trust domain — over a single day on one phone they move through public posting, semi-trusted group chat, and high-stakes private coordination. The architecture has to make which zone you are in legible and enforce the boundaries in code, not convention.
A zone is three axes, not one label¶
The single biggest correction from the candidate research: a one-word zone label ("secure" / "open") is too coarse and actively dangerous. Damus/Nostr is the proof — its DMs are content-encrypted ("secure") yet leak the social graph ("open"). Score every zone, channel, and candidate on three independent axes:
| Axis | Question | Failure if weak |
|---|---|---|
| 1. Content confidentiality | Is the payload encrypted end-to-end? | Anyone in the path reads the message |
| 2. Metadata exposure | Is the social graph / timing / size hidden? | "Who talks to whom, when" is reconstructable even with encrypted content |
| 3. Network identity | Is your IP / key-linkage protected? | You are deanonymized to relay operators / network observers regardless of content |
A candidate can be Strong / Medium / Weak on each, simultaneously and differently. Collapsing them to a single "level" hides the exact risk that matters for a vulnerable user (e.g. a reentry or recovery context where metadata — who you associate with — is the threat, not message text).
The four device-level zones¶
Mapped onto how a user actually behaves, and onto MPowerUP's existing structure:
| Zone | What the user is doing | Architecture shape | MPowerUP mapping | Axis profile (target) |
|---|---|---|---|---|
| Z0 · Off-grid / local | Coordinating with people physically nearby, no internet | P2P over BLE/Wi-Fi mesh (Briar-style) | Aspirational — the true offline tier MPowerUP doesn't yet have | content Strong / metadata Strong (local-only) / network-id N/A (no IP) |
| Z1 · Private Circle | Trusted mutual-aid group, help requests, location | Relay-assisted P2P / onion | MPowerUP's Circles today (Yjs+WebRTC); could add Tor | content Strong / metadata Medium→Strong / network-id Weak→Strong |
| Z2 · Federated / discovery | Finding services, semi-public reach | Client–relay / federated | Service discovery (Overpass today); a future public layer | content Medium / metadata Weak / network-id Weak |
| Z3 · Open / unsecured | Public posting, max reach & interop | Centralized / ActivityPub / public Nostr | Not currently in MPowerUP; would be opt-in | assume fully observable on all axes |
The privacy cost rises and reach falls as you go Z3 → Z0. A user moves down into Z0/Z1 for sensitive coordination and up into Z2/Z3 for discovery and reach.
Zones describe application topology, not deployment substrate. Where you run the code (a hyperscaler VM, an EU VPS, self-hosted refurb hardware) is a separate axis that can compromise sovereignty even when the topology is decentralized — a Z2 federated service still leaks to its host operator. See the cloud-providers sovereignty matrix, and the
Operator/Zone (Ops)columns in the tool tracker, for that axis.Numbering caveat: this page's device-interaction model (
Z0off-grid →Z3open) is not the same scale as the network-architecture model used incloud-providers.mdand the tool tracker (1= P2P →4= centralized). They are related framings but invert direction and do not map 1:1 — don't read "Zone 4" there as this page's "Z3" without checking.
The two design questions the model forces¶
These are the load-bearing decisions — most of the platform is decided here:
1. Are zones a property of the conversation/channel, or of the user's current mode?
- Per-channel: "this Circle is Z1, that broadcast is Z3." Cleaner mental model; each conversation carries its own axis profile. Recommended starting point [HYPOTHESIS] — it matches MPowerUP's existing per-Circle YDoc boundary, so the zone boundary is already a code boundary.
- Per-mode: "I am in secure mode right now." Simpler UI but couples unrelated conversations and risks mode-confusion errors.
2. When data must cross a zone boundary, what happens? (e.g. inviting a Z2 federated-only contact into a Z1 Circle, or someone trying to quote a Z1 help request into Z3) - Block — refuse the crossing. Safest, most limiting. - Warn-and-downgrade — allow, but make the privacy loss explicit and require confirmation. - Bridge-with-label — allow, carry a persistent security label so the lower-trust origin is always visible.
This single decision (block / warn-downgrade / bridge-label) is, per the original research, "most of the platform." It must be enforced in code and visible in UI, never left to user convention.
What makes the model work vs. become a trap¶
- The user must always know which zone they are in — legible at a glance, not buried in settings.
- Data must not silently cross zone boundaries. The classic failures: a Z1 message forwarded into Z3; a contact's Z1 identity correlated to their Z3 public identity. Both must be structurally prevented, not discouraged.
- Boundaries are enforced in code, not by convention. MPowerUP's per-Circle key + per-Circle
YDocalready gives a natural enforcement seam — the zone boundary should ride on the same boundary as the encryption boundary.
Using the model to read the candidates¶
Every candidate note ends with its three-axis zone placement. The decision matrix collects them. Quick orientation:
- Strong on all three axes: Cwtch, Briar (online over Tor) — the metadata-resistant Tor apps. Cost: battery, and (Cwtch) no Z0 offline tier.
- Strong content + metadata, Medium network-id: SimpleX (network-id only Strong with Tor enabled).
- Strong content, Weak metadata + network-id: Nostr, Matrix, XMPP — encryption is fine; the identifier/server model leaks the rest.
- Weak on all three: ActivityPub (no E2E at all), centralized baselines.
- Z0-capable (the rare offline tier): only Briar (mature) and Berty (alpha) provide genuine local-mesh; everything else needs the internet.
The gap this exposes for MPowerUP: it has a credible Z1, a partial Z2, no Z0, and no Z3. The verdict prioritizes closing the Z0 (offline mesh) and network-identity gaps, because those are where the existing field is both strongest and most relevant to vulnerable users.