The Dits mental model
Dits records exact project states over chunked content-addressed storage. Media semantics and remote collaboration build on that foundation rather than replacing it.
Repository
A repository combines a working tree, staged state, immutable content, manifests, commits, and refs beneath local .dits metadata. The repository on disk is the current source of truth; there is no hosted control plane required for local commands.
Exact objects and chunks
Large binary content is divided with FastCDC. Stored chunks are named by BLAKE3 content identifiers, so byte-identical chunks can share one local object. A digest identifies exact bytes—it does not mean two visually similar frames or numerically close tensors are the same object.
Content-defined boundaries can preserve reuse around local insertions, but they do not guarantee savings. Compression, encryption, opaque containers, and full media re-encodes may change nearly every byte.
Manifest
A manifest records how a file or asset is reconstructed from ordered content. It must carry enough length, order, type, and version information to reject missing, corrupt, or incompatible data. Deterministic encoding matters when identifiers depend on serialized bytes.
Commit and ref
A commit records a project state and its relationship to previous states. Branches and tags are refs to commits. Git-shaped commands expose local history, but Dits does not imply wire compatibility with Git or a stable Dits remote protocol.
Hybrid text and binary handling
Current code can route text-oriented paths through libgit2 behavior while large binary content uses Dits manifests and chunks. The goal is to retain useful text diffs and merges without storing every large binary revision as one unrelated object.
Source, edit, dependency, and rendition
The research model distinguishes immutable source bytes from explicit edit decisions, dependency relationships, and derived renditions such as proxies or exports. A rendition may be regenerable; the source remains the archival authority. FACR, photo edit logs, dependencies, and proxy paths are experiments toward this graph, not a stable universal format.
Availability and hydration
A future repository may know an object without holding it locally and hydrate verified ranges or chunks on demand. Today, remote hydration and partial network clone are not implemented. Local VFS behavior is experimental and must not be described as instant remote access.
Integrity and recovery
Reads should verify identifiers and lengths, writes should become visible atomically, and refs should never point at incomplete object graphs. The current engine has integrity-oriented paths, but crash safety and recovery matrices remain active roadmap gates.