architecture
System Diagram
The architecture in one page, plus the three rules that hold it together.
The whole system
Project
my-game-prototype
manifoldone.ai/p/my-game-prototype
↓ ws ↓ ws ↓ ws ↓
Worker · docked
danny-mbp
Frontend branch
● online · 3 users
Worker · docked
office-tower-01
Game-engine branch
● online · 2 users
Worker · docked
build-server-aws
Backend / CI
● online · 1 user
↓ chat ↓
user1
user2
user3
user11
user12
user21
Three roles. Each one obeys exactly one rule.
The three rules
We inherited these from estelle, where they were proven to keep a multi-device sync system from collapsing into spaghetti. Manifoldone extends them from a 1:1:1 system to N:M:1 — but the rules don’t change.
Rule 1
Node = Single Source of Truth
The local Node is the only thing that mutates state. All other components read from it.
node.state = mutate(...)
broadcast(state) → relay Rule 2
Relay = Pure Function
The relay is a stateless router. It validates auth and forwards. It never holds Thread data.
route(msg, auth) →
authorized clients Rule 3
Client = Display-Only
Clients render and emit intent. They never directly mutate state. The Node is always the executor.
client.cmd("intent")
→ node.execute() Why these rules matter for multi-Node
When you go from 1 Node to N Nodes sharing a project, the failure modes multiply. The three rules collapse most of them:
- No double-write. Only Nodes mutate; conflicts can only happen at the VCS layer (where they belong).
- No relay state to lose. Restarting a relay instance is safe.
- No rogue client. A misbehaving client can only send intent; it can’t corrupt anyone else’s state.
What we extended
The estelle baseline was 1 Pylon : 1 user : 1 project. Manifoldone (which renamed Pylon to Node for clarity) adds three things:
- Multi-Node federation. A project has multiple Nodes. The relay knows which Nodes belong to which project and routes accordingly.
- Node health and queueing. The relay tracks Node availability and can buffer intent if a Node is briefly disconnected.
- Permission scopes. Project membership and role gate which Threads a client can subscribe to.
The original Node=SSOT, Relay=pure, Client=display rules survive all three additions unchanged. The estelle README explicitly notes that “multi-Pylon (multiple PCs running Pylon simultaneously) is not yet tested” — that’s the territory Manifoldone occupies.
Wire format borrowed from Soulstream
The on-the-wire event vocabulary (init, text_delta, complete, error, plus our Thread/tool frames) is borrowed directly from Soulstream’s “Claude Code as a Service” pattern. See tech_architecture.md §3 for the schema; see Inspirations for credit.