Bindhub vs Loom
Bindhub is the product users open. Loom is the engine direction underneath Bindhub. The user-facing promise stays focused on folders, machines, and trust while Loom supplies the lower-level model.
Shared folders
A shared folder is the folder the user wants to keep continuous across machines. It might contain many repos, one repo, no repo, nested apps, secrets, dependencies, generated files, and agent work.
File versions and folder revisions
Loom captures file versions frequently. It coalesces them into folder revisions at stable boundaries such as debounce windows, Loom commands, sync, restore, sandbox merge, and checkpoint creation.
Machines and cursors
A cursor is a moving pointer for a machine, remote, or materialized folder state. Cursors let Bindhub explain which state each side believes is current before syncing, restoring, or merging.
Hydration and cache
Hydration state records whether object bytes are remote-only, partial, or fully local. Cache entries track byte availability separately from file versions and folder revisions.
Hosted auth
The dashboard uses WorkOS/AuthKit as the hosted authentication direction. Server code exchanges the verified WorkOS session with the hosted Bindhub API instead of exposing WorkOS access tokens to browser code.
Agents and workspaces
Agents need isolated workspaces and sandboxes so parallel work can be reviewed and merged without damaging the shared folder a human trusts. Overlays cover local non-source state such as dependencies, caches, configuration, and secrets.