Content addressing
An object is named by a cryptographic digest of exact bytes, making integrity verification and exact reuse part of the storage model.
Identity
Dits uses BLAKE3 content identifiers in its current local chunk store. A reader recomputes the digest and checks length before trusting imported or stored bytes. The identifier says nothing about filename, ownership, artistic meaning, or perceptual similarity.
Indirection
Paths and commits do not need to contain large payloads directly. They can reference versioned manifests, which in turn reference ordered content objects. Multiple manifests may reference one exact chunk.
Atomic visibility
A trustworthy store writes to a temporary location, flushes and verifies the complete object, then publishes it atomically. A ref update should not expose a commit until every required object is durable. Hardening these crash and recovery semantics is a current roadmap gate.
Security boundary
A digest detects accidental or adversarial byte changes; it does not authenticate an author or authorize access. Identity, authorization, encryption keys, signatures, and remote policy are separate layers.
Format stability
If an object ID includes serialized metadata, the encoding must be deterministic and versioned. Dits has not yet declared its repository format a stable third-party contract; conformance vectors and migration behavior come before that promise.