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
machine A ──┐ ┌── machine B
│ NATS + JetStream │
c3syncd ───┼──► private hub ◄────┼─── c3syncd
│ stores ciphertext │
machine C ──┘ └── offline peers catch upThe 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.