Skip to content
C3Control / Continuity
Mobile documentation

C3 Mobile / Core concepts

Updated 2026-07-24

Architecture

text
C3 Mobile ── pinned WSS + E2EE ── C3 Hub (C3_CONTROL) ── TLS + E2EE ── C3 Bridge ── Herdr ── agents
C3 Desktop ────────┘

One connection, many machines

Each client holds one connection to your hub. Over it, the phone or desktop discovers every bridge paired with that client, receives events, and sends control commands. Adding a machine adds a bridge — never a direct client-to-machine network path.

Discovery is active and replay-resistant: each refresh sends a freshly random request that bridges answer with a signed response, so a stale or spoofed host can't linger on your Signal map.

The hub routes ciphertext

The hub is a NATS server provisioned by c3sync hub init. For C3 Mobile it does exactly one job: route encrypted messages between phone and bridges. Commands and events are sealed on the endpoints; the hub sees message subjects, sizes, and timing — never prompts, terminal frames, or filenames.

Control traffic is ephemeral by design. It uses plain publish/subscribe (no persistence), and every command carries a short expiry — an instruction that isn't delivered within seconds dies rather than executing later. The app also refuses to send anything while its connection is down, so there is no offline queue to replay surprises from.

The bridge is the hands

On each machine, c3bridge connects out to the hub (TLS, port 4222) and to Herdr's local socket. It translates decrypted commands into Herdr operations — create a workspace, split a pane, type into a terminal — and streams Herdr's events and PTY output back, encrypted per pair. The bridge is also what sends push notifications when an agent needs you.

Herdr is where your agents actually live: workspaces containing tabs containing panes, with agents attached to panes. C3 never speaks to the agent or its vendor directly — it operates the same terminals you would at the desk. See sessions & workspaces.

Sharing a hub with C3Sync

The hub carries two NATS accounts, created together at hub init:

  • C3_SYNC — C3Sync's durable, encrypted session/file sync (JetStream).
  • C3_CONTROL — C3 Mobile, C3 Desktop, and C3 Bridge traffic (ephemeral core NATS).

The accounts are isolated by the NATS operator model: control credentials cannot subscribe to sync subjects, so a phone or bridge — even a compromised one — can never read your synced session history. Both accounts trust the same CA pin, which is why one enrollment infrastructure serves the whole suite.

You can run C3 Mobile without ever enabling C3Sync, and vice versa. The only shared requirements are the hub machine and the c3sync CLI that administers it.

Trust in one table

PartySeesCan do
HubSubjects, sizes, timingRoute, delay, or drop messages
BridgeEverything on its own machineAct on its own Herdr only
Phone or desktop clientDecrypted state of paired bridgesCommand its paired bridges only
Push services (FCM/APNs)"An agent needs your attention"Wake the app

What this deliberately does not defend against is covered honestly in the security model.