Question 1

What is Dits?

Accepted Answer

Dits is open-source, Git-like version control built for large media — video, photos, 3D, and game assets — instead of code. It splits every file into content-defined chunks, addresses each chunk by its BLAKE3 hash, and stores each unique chunk once. So you get real commits, branches, and history over multi-gigabyte files, and you only store and move what actually changed.

Question 2

Who is it for?

Accepted Answer

Video editors, photographers, 3D artists, game developers — anyone whose 'version control' today is a folder of final_v3.mp4 files in Dropbox. If your projects are big, binary, and constantly revised, Dits gives them the history and deduplication that Git gave code.

Question 3

How is this different from regular Git?

Accepted Answer

Git is brilliant for text and miserable for big binaries — it stores a full copy of every version and can't diff inside a video. Dits keeps Git's mental model (commits, branches, history) but rebuilds the storage layer around content-defined chunking and large-file streaming, with a virtual filesystem and binary locking on top. Same workflow, built for the heavy stuff.

Question 4

Is it really free and open source?

Accepted Answer

Yes — Dits is open source under the MIT license. No usage limits, no file-size caps, no account required, and you can self-host everything on your own infrastructure.

Question 5

Do I need to know Git to use it?

Accepted Answer

It helps, because the commands deliberately mirror Git (init, add, commit, status, diff, log, branch, checkout). But the concepts are intuitive even if you've never touched Git — you're saving versions of a project and able to jump back to any of them.

Question 6

What's the difference between Dits for media and Dits for AI?

Accepted Answer

Same engine, different heaviest files. This surface — Dits for media — versions video, photos, and creative assets. Dits for AI points the identical content-addressed engine at model weights, datasets, and research data. Improvements to the core benefit both.

Question 7

How does Dits compare to Git LFS?

Accepted Answer

Git LFS stores each version of a file as a complete copy — five versions of a 10 GB video is 50 GB. Dits uses content-defined chunking, so those versions share their unchanged pieces and take far less space. LFS also re-uploads the whole file on every change; Dits's content-addressed store is designed so sync only moves the changed chunks (that networked sync engine is still in development).

Question 8

Why not just use Dropbox or Google Drive?

Accepted Answer

Cloud drives sync files, they don't version projects. They store a fresh full copy on every change, have no real history of what changed or why, and can't deduplicate the 95% of a file that stayed the same. Dits gives you commits, diffs, and history while storing only the delta.

Question 9

Why not a NAS or shared drive?

Accepted Answer

A NAS is great storage but knows nothing about versions — you still end up with manual naming conventions and 'who overwrote my edit?' Dits adds content-addressed history and binary locking on top, and can use a NAS or S3 as its backing store.

Question 10

How does it compare to Perforce / Helix Core?

Accepted Answer

Perforce is the incumbent for big-binary teams, but it's centralized, proprietary, and priced accordingly, and dedup needs explicit setup. Dits is open-source, distributed, content-addressed, and deduplicates automatically across versions — the open alternative for teams that only use Perforce because Git couldn't handle their files.

Question 11

How is it different from rsync or Syncthing?

Accepted Answer

Those move and mirror bytes between machines; they don't give you versioned history, commits, or the ability to check out a past state of a project. Dits is a version control system — sync is one feature, not the whole product.

Question 12

How does it compare to Frame.io or a media asset manager?

Accepted Answer

Those are review, sharing, and cataloging layers — they sit on top of your files. Dits is the version control underneath: the source of truth for what changed, when, and how to reconstruct any past version efficiently. They're complementary, not competitors.

Question 13

Why not just rename files (final_v3.mp4)?

Accepted Answer

Because renaming is a versioning system with no history, no diff, no dedup, and no answer to 'which one actually shipped?' Every 'version' is another full copy on disk. Dits replaces the naming convention with real commits while storing only what changed.

Question 14

What file types does Dits support?

Accepted Answer

Any file type. It's especially optimized for video (MP4, MOV, MXF), 3D assets (FBX, OBJ, Blender, USD), game projects (Unity, Unreal), and creative tools (PSD, Premiere and Resolve projects) — but the universal chunker handles anything.

Question 15

How well does it work with video specifically?

Accepted Answer

Video is the flagship case. Dits understands MP4/MOV container structure — it chunks the media payload separately from metadata and can align chunk boundaries to keyframes, so a small edit touches a few chunks instead of the whole file, and metadata-only changes barely cost anything.

Question 16

What about RAW photos and PSDs?

Accepted Answer

Both work. PSDs change many bytes when you tweak a layer, but content-defined chunking still captures the unchanged layers, and shared structure across versions and exports dedupes. RAW sets dedupe well because originals never change — only your edits and derivatives version on top.

Question 17

3D assets — Blender, FBX, OBJ, USD?

Accepted Answer

Supported. Large scene files chunk and dedupe; the best results come from referenced (rather than embedded) assets, so shared models and textures are stored once across scenes. Dits is tested across these formats.

Question 18

Game projects — Unity and Unreal?

Accepted Answer

Yes — large binary game assets are a core use case. Because they're not mergeable, Dits leans on content-defined chunking to store only changed regions, plus file locking to prevent two people clobbering the same asset.

Question 19

What about audio sessions?

Accepted Answer

They work like any other project files — large session files and sample libraries chunk and dedupe, and unchanged stems or samples are stored once across versions.

Question 20

What is keyframe alignment / atom awareness?

Accepted Answer

For video, Dits parses the container (e.g. MP4 atoms) and tries to place chunk boundaries on keyframes. That keeps each chunk independently decodable, improves deduplication after edits, and means changing a clip's metadata doesn't force a re-store of the whole thing.

Question 21

How does content-defined chunking work?

Accepted Answer

Instead of cutting files at fixed offsets, Dits uses a rolling hash (FastCDC) to choose boundaries based on the content itself. So when you insert or delete data in the middle of a file, only the chunks near the change shift — the rest keep their hashes and dedupe. Each chunk is addressed by its BLAKE3 hash.

Question 22

How much storage will I actually save?

Accepted Answer

It depends on your content and edit patterns, so we won't quote one magic number. The mechanism is simple: anything two versions share is stored once. Iterative video edits, revision-heavy projects, and reused assets see the biggest wins; a library of totally unrelated files sees the least.

Question 23

What happens if I trim or edit the middle of a video?

Accepted Answer

Only the affected chunks change. Trim the start and roughly the changed region re-stores; tweak a few seconds in the middle and you pay for a few chunks, not the whole multi-gigabyte file. The unchanged remainder keeps its existing chunks.

Question 24

Does re-encoding or transcoding dedupe?

Accepted Answer

Honestly, not much — a full re-encode changes nearly every byte, so the new render shares little with the old one. Dits still versions it with full history and integrity; it just can't dedupe bytes that genuinely changed. Where it shines is edits and metadata changes, not whole-file re-encodes.

Question 25

When does dedup NOT help?

Accepted Answer

When a change rewrites the whole file: re-encoding, recompressing, or an export that touches every byte. You still get version history, integrity-checked storage, and dedup against related files — just not against the previous full render. We'd rather be upfront than overpromise.

Question 26

What is FACR (frame-addressable video)?

Accepted Answer

FACR is an experimental, frame-level representation that lets Dits diff and dedupe video at the granularity of individual frames rather than byte ranges — so two cuts that share footage can share frames directly. It's early and labeled experimental; you can try it today with `dits facr-demo`.

Question 27

What is the virtual filesystem (VFS)?

Accepted Answer

Dits can mount a repository as a normal drive (FUSE on macOS/Linux, Dokany/WinFSP on Windows). You see the full project structure instantly, and when you open a file, Dits fetches just the chunks it needs and reconstructs it on demand — no full download required.

Question 28

Can I work with files bigger than my disk?

Accepted Answer

That's exactly what the mount enables: the repository can be far larger than local disk, and files hydrate on access while a cache keeps recent ones fast. You browse and open what you need without materializing everything.

Question 29

What's the maximum file size?

Accepted Answer

There's no hard limit. Dits streams chunking so memory stays bounded regardless of size, and files past 100 GB have been tested successfully.

Question 30

How do proxies / 'hologram' editing work?

Accepted Answer

Dits can generate and check out lower-res proxies so you can edit smoothly without the full-resolution source, then relink to originals later. Proxy generation and checkout work today; the fuller on-the-fly 'hologram' experience (Phase 6) is on the roadmap.

Question 31

Does it work with my NLE — Premiere, Resolve, Final Cut?

Accepted Answer

Yes. Because the VFS mount makes a Dits repo look like an ordinary folder, any application that reads files works unchanged — Premiere, DaVinci Resolve, Blender, Unity, Unreal, and more. Deeper, plugin-level integrations are a later roadmap phase.

Question 32

What commands does it use?

Accepted Answer

The Git-familiar set — dits init, add, commit, status, diff, log, branch, checkout, merge, stash, tag — plus media-specific ones for proxies, mounting, and video. If you know Git, you're productive on day one.

Question 33

How do I start a project?

Accepted Answer

Run `dits init` in your project folder, `dits add .` to stage your files, and `dits commit -m "Initial"`. That's it — you now have a versioned project, and every future commit stores only what changed.

Question 34

How do I see what changed between versions?

Accepted Answer

`dits log` shows history and `dits diff` compares versions — for media, that means showing which chunks (and, with FACR, which frames) changed rather than a meaningless byte dump. You can see how much of an asset actually moved between cuts.

Question 35

Can I branch and merge?

Accepted Answer

Yes — branching, merging, tags, and stash all work (Git parity is complete). For text-like project files, normal merging applies; for binary assets that can't be merged, you use locking to avoid conflicts instead.

Question 36

How do I undo or go back to an old cut?

Accepted Answer

Check out any past commit, branch, or tag to restore that exact state byte-for-byte (`dits checkout`), or use restore/reset to roll specific files back. Your full history is always recoverable as long as the commit exists.

Question 37

Does it integrate with my existing Git repo?

Accepted Answer

Yes — Dits uses a hybrid model that keeps text in Git and large binaries in the Dits chunk store, so you can run them side by side. Many teams keep code in Git and media in Dits in the same project.

Question 38

Can multiple people work on the same project?

Accepted Answer

Yes. Dits uses a commit history like Git, and for binary assets that can't be auto-merged it adds explicit locking so two people don't overwrite each other. The seamless multi-machine experience depends on the networked sync engine, which is in active development.

Question 39

How does locking work for binary files?

Accepted Answer

Run `dits lock <file>` before you edit a non-mergeable asset and others see it as read-only until you unlock. It's the standard way to prevent binary conflicts. Local locking works today; fully server-coordinated multi-user locking is being finalized.

Question 40

Is there networked sync today?

Accepted Answer

Local operations and local clone/push work today. The networked delta-sync engine over QUIC (push/pull/fetch across the internet, resumable transfers) is on the roadmap and in active development — those network commands are currently scaffolding, and we say so rather than implying they're done.

Question 41

Can I self-host a server?

Accepted Answer

That's the intended model — the protocol and formats are open and self-hostable, with S3-compatible storage backends. The hosted convenience layer (Ditshub) is optional; everything it does is possible on infrastructure you control.

Question 42

Is there P2P sharing?

Accepted Answer

It's on the roadmap — clients sharing chunks directly without always going through a server. It's part of the sync design but not shipped yet; today, sync is local and self-hosted.

Question 43

What does a 100-person team workflow look like?

Accepted Answer

The intended shape: one editor pushes a small project delta plus only the changed assets, everyone else pulls instantly, and source media stays local or cached so it's fetched once and reused. The local model and locking exist today; the instant team experience depends on the networked sync engine in development.

Question 44

Where is my data stored?

Accepted Answer

Locally by default — Dits is local-first and works fully offline. For remotes you can use S3-compatible backends or self-hosted storage like MinIO. Nothing leaves your machine unless you explicitly push.

Question 45

Is my data encrypted?

Accepted Answer

The engine supports convergent encryption (AES-256-GCM), which keeps chunks confidential while still allowing deduplication. And because it's local-first, the strongest guarantee is simple: your files don't go anywhere unless you send them.

Question 46

How does it prevent corruption?

Accepted Answer

Every chunk is addressed by its BLAKE3 hash and verified on read — if bytes don't match the hash, Dits detects it and restores from another copy. Checksum verification is mandatory and can't be silently skipped, so silent corruption doesn't slip through.

Question 47

Can I recover deleted files or old versions?

Accepted Answer

Yes — as long as the commit exists you can check it out and get those files back byte-for-byte. Chunks are reference-counted and only garbage-collected when nothing points to them, so history stays intact until you intentionally prune.

Question 48

Does it phone home or require an account?

Accepted Answer

No. The open-source core needs no account and no network connection to work — init, commit, diff, branch, and checkout are all local. You only connect when you choose to sync.

Question 49

Is it production-ready?

Accepted Answer

It's in active development and honest about it. The local engine — chunking, dedup, byte-exact checkout, MP4 structure awareness, the VFS mount, and Git-parity history — works today; networked sync, P2P, and the full hologram and frame engine are in progress. Great for early adopters; check the roadmap before depending on a specific feature.

Question 50

What works today vs. what's on the roadmap?

Accepted Answer

Working today: local chunking/dedup with byte-exact checkout, MP4 atom-aware handling, the FUSE/WinFSP virtual filesystem, Git parity (branch/merge/tags/stash), hybrid Git+Dits storage, proxy checkout, and local clone/push. Roadmap: networked QUIC delta sync, P2P sharing, the full hologram proxy experience, and the FACR frame engine (experimental today). Roadmap items are labeled throughout.

Question 51

How do I install it?

Accepted Answer

One line via the install script, or Homebrew, npm/bun/pnpm, Cargo, or a prebuilt binary from GitHub Releases. Then run `dits init` in any project to get started — see the Download page for all options.

Question 52

How do I contribute or follow progress?

Accepted Answer

Dits is developed in the open on GitHub — follow the repo, open issues, and join discussions. There's a long list of genuinely open problems, so design ideas, prototypes, and research are as welcome as code.

Questions, answered honestly

The basics

How it compares

File types & formats

How chunking & dedup work

Virtual filesystem & big files

Workflow & commands

Teams, locking & sync

Storage, safety & security

Status & roadmap

Still have a question?

Try it live

See the numbers

Dits for AI