Skip to content
C3Control / Continuity
Sync documentation
C3Sync

C3Sync / Core concepts

Updated 2026-07-24 · C3Sync README and security model

Architecture

Each enrolled machine runs c3syncd. The daemon watches native agent session stores and enabled working trees, turns changes into encrypted events, and consumes events produced by peers.

Topology

text
machine A ──┐                        ┌── machine B
            │   NATS + JetStream     │
 c3syncd ───┼──►  private hub   ◄────┼─── c3syncd
            │   stores ciphertext    │
machine C ──┘                        └── offline peers catch up

The hub provides routing, durable streams, and object storage. It does not receive the content keys needed to open payloads.

The same hub also serves the rest of the C3 suite: alongside the C3_SYNC account it exposes a certificate-pinned WebSocket listener (port 8443) and an isolated C3_CONTROL account for C3 Mobile phones and C3 Bridge hosts. The accounts cannot read each other's subjects — mobile control traffic never touches sync data. One hub init provisions both.

Session channel

Agent adapters read and write each provider's native on-disk session format. Session events form an append-only log ordered with hybrid logical clocks, so a peer can materialize the conversation in the format its local agent expects.

File channel

At agent-turn boundaries, C3Sync captures the git-visible working tree. Files merge per path. Non-overlapping changes combine; concurrent changes to one path resolve deterministically while preserving the losing bytes in a .conflict sidecar.

Project identity

Git projects derive identity from repository history and origin rather than absolute filesystem paths. Non-git folders can synchronize transcripts but do not participate in working-tree synchronization.