Hey!
We are rewriting Nix using LLMs, splitting into layers.
Casita is the first standalone layer, a content-addressed object store for source code and build artifacts, with deduplication, verification, synchronization, and garbage collection.
For full explaination on why and what it supports today, see
Is the blog actually from August 25th?
Forgot to bump it, that’s when I wrote the draft. Thanks!
Thanks for your hard work on implementing so many initiatives.
Question from someone discovering the variety of tools around Nix: what is the difference between Casita and Snix-castore ?
Great question, I should probably write this up.
Here you go, a bit of brain dump.
Casita is Apache2, snix is GPL3, this is really important for our mission to mainstream Nix.
Casita defines a generic object graph, so you can express a lot of things with simple trait implementations of CustomFormat or Importer, where as in snix there’s a concept of services doing things, implementing their own logic including storage.
That means you can fully express Casita as a backend for Git, including all mutable bits.
Another way to look at this, in Casita you have one store for blobs and another store for all immutable and mutable metadata, (like git refs) expressed via roots.
At the feature level, snix doesn’t have a lot of higher-level things like GC, WAL S3.
I also have a branch with CasitaFS sketched out, kernel filesystem implemented in Rust. That’s the end goal in term of performance.
Casita also doesn’t have any of the gRPC stuff, it’s all pure Rust, but you can implement your own sync protocols.
It does support rsync-style sync protocol to sync difference between two machines.
So, is this also a VCS? That’s wild!
A storage backend for it yes, I have a branch that integrates it into git!
When you think about it makes sense, git should store stuff into a filesystem that chunks and then when you import that voila - it’s the same data!
Good idea, but Claude is contributor #3.. would have liked a disclosure up front.
This is so cool! 
I love that it’s completely generic. I think it should even be possible to import Docker images, right?
Seems like a disclosure to me.
Git does a lot of work on the backend to pack deltas down to small sizes, and optimize the on-disk representation. Is this something that’s planned for Casita? I remember Git on IPFS suffering the same issue of inability to store diffs and huge storage sizes.
Re: CasitaFS, instead of building your own filesystem, could you use ZFS blocks for storage?
That disclosure did not exist at the time of my comment and was edited ~away~ in afterwards.
Better than nothing.
Now it does! Import an OCI Image | Casita
We use packs as well! That’s why you can think of it as a generalized Git.
You can already use ZFS underneath, although there’s benefits for a native filesystem.
Was the name inspired by Casa? 
Assuming Casita is successful, could you imagine it being useful as a replacement backend for casa.stackage.org? Not that there’s anything wrong with the current backend… apart from its total lack of other users. Hackage itself also needs a better storage backend and transport layer. Currently you either get a 1GB tarball or an unwieldy git repo. Do you see any opportunity for synergy here?
I had no idea Casa existed, and I’ve searched quite a bit if someone has the same association!
Very cool to see it, package managers like Haskell/Cabal would integrate IPC to store artifacts and would then also benefits from wider ecosystem adoption.
I recommend to read the bupstash source code.
Good choice on BLAKE3; also read bao as verified streaming is a nice feature for syncing and can prevent DoS attacks.
Deduplication | Casita is too short in my opinion, would like more detail.
The docs need a lot of work, I’m focusing on correctness and performance first, docs are after that.
Thanks @nh2
I’m curious about this, what is your end goal? this new rust nix will be compatible with the cppnix?