Presets are written in Jsonnet, and resolve to a list of things to pass through from the parent process into the container.
Presets can reference other presets, so you can build up arbitrary rules for passing files and devices into containers, give those rules a name, and reference them later.
It looks like this treats files as blobs just like Git, and trees as single objects which fit in memory. Assuming that is a correct understanding, this core abstraction would need to change to handle large files and directories well.
All the well known version control systems do this though, and it simplifies the system significantly. It's the right model for source code, but it doesn't translate well to arbitrary data.
I've heard that jj has support for non-git backends?
Can anyone comment on how difficult it would be to add support for another backend, any docs or examples?
I have a project[0] that does the large file thing well, but is missing most of the version control porcelain.
I've been looking for the path of least resistance to integrate it into something with a larger user base.
> The problem is when you move beyond text files it gets hard to tell what changes between two versions without opening both versions in whatever program they come from and comparing.
Yeah, totally agree. Got has not solved conflict resolution for arbitrary files. However, we can tell the user where the files differ, and that the file has changed.
There is still value in being able to import files and directories of arbitrary sizes, and having the data encrypted.
This is the necessary infrastructure to be able to do distributed version control on large amounts of private data. You can't do that easily with Git. It's very clunky even with remote helpers and LFS.
I talk about that in the Why Got? section of the docs.
Notable differences: E2E encryption, parallel imports (Got will light up all your cores), and a data structure that supports large files and directories.
I also wrote a tool for doing this[0], after one of these agents edited a config file outside of the repo it was supposed to work within.
I only realized the edit because I have my dotfiles symlinked to a git repository, and git status showed it when I was committing another change.
It's likely that the agents are making changes that I (and others) are not aware of because there is no easy way to detect them.
The approach I started taking is mounting the directory, that I want the agent to work on, into a container.
I use `/_` as the working directory, and have built up some practices around that convention; that's the only directory that I want it to make changes to.
I also mount any config it might need as read-only.
The standard tools like claude code, goose, charm, whatever else, should really spawn the agent (or MCP server?) in another process in a container, and pipe context in and out over stdin/stdout.
I want a tool for managing agents, and I want each agent to be its own process, in its own container.
But just locking up the whole mess seems to work for now.
I see some people in the other comments iterating on what the precise arguments to bubblewrap should be. nnc lets you write presets in Jsonnet, and then refer them by name on the command line, so you can version and share the set of resources that you give to an agent or subprocess.
I personally think that this is the future, especially since such an architecture allows for E2E encryption of the entire database.
The protocol should just be a transaction layer for coordinating changes of opaque blobs.
All of the complexity lives on the client.
That makes a lot of sense for a package manager because it's something lots of people want to run, but no one really wants to host.
Blobcache is a content-addressed data store for holding application state, and buiding E2EE applications.
This most recent release includes a git remote so you can push and fetch Git data into and out of Blobcache.
I'm a happy bcachefs user. Haven't had any issues on a simple mirrored array, which I've been running since before it was in (and out) of the kernel. It's the best filesystem in 2025. Thank you for all your work.
What is the status of scrub?
Are there any technical barriers to implementing it, or is it just prioritization at this point?
FWIW I think there are probably a lot of sysadmin types who would move over to bcachefs if scrub was implemented. I know there are other cooler features like RS and send/receive, but those probably aren't blocking many from switching over.
I work on a project Blobcache, a content addressed store for exposing and consuming storage over the network.
It supports full end to end encryption, and offers a minimal API to prevent applications from leaking data.
You can persist arbitrary hash-linked data structures in Blobcache volumes.
One such data structure is the Git-Like Filesystem, which supports the usual files and trees.
The same API part isn't surprising, content addressed stores are the most natural way to accept encrypted data.
The public storage networks are targeting a different use case than Blobcache though, which I think of as a private or web-of-trust storage network. To use a cryptocurrency backed storage solution, one must manage accounts, or a wallet of transaction outputs, connect to unknown parties on the internet, and pay for the increased redundancy.
There's also legal risk, depending on the jurisdiction, when allowing untrusted parties to store arbitrary information on one's devices.
I don't want to consult the global economy in order to make use of my extra hard drives, which would otherwise be idle.
I couldn't find an email in your bio. You can reach me via the email at the bottom of my website (in my HN bio).
Looking through the docs on Peergos, it looks like it's built on top of IPFS.
I've been meaning to write some documentation for Blobcache comparing it to IPFS. I can give a quick gist here.
Blobcache Volumes are similar to an IPNS name, and the set of IPFS blocks that can be transitively reached from it.
A significant difference is that Blobcache Volumes expose a transaction API with serializable isolation semantics.
IPFS provides distributed, available-but-inconsistent, cryptographically signed cells.
IPFS chooses availability, and Blobcache chooses consistency.
A Blobcache Volume corresponds to a specific entity maintained and controlled by a specific Node.
An IPFS name exists as a distributed entity on the network.
Most applications need some sort of consistent transactional cell (even if they don't realize it), but in order to be useful, inconsistent-but-available cells have to be used carefully in an application specific way.
I blame this required application-specific care for the lack of adoption of CRDTs.
There's a long tail of other differences too.
IPFS was pretty badly behaved the last time I used it, trying to configure my router, and creating lots of connections to other nodes.
Blobcache is more like a web browser; it creates transient connections in immediate response to user actions.
That whole ecosystem is filled with complicated abstractions. Just as an example, the Multihash format is pervasive.
It amounts to a tag for the algorithm used to create a hash, and then the hash output.
I'd rather not have that indirection.
All the hashes in Blobcache are 256 bits, and you set the algorithm per Volume.
In Go that means the hashes can just be `[32]byte` instead of a slice and a tag and a table of algorithms.
I haven't used IPFS in a while, but I became pretty familiar with it awhile ago. Had I been able to build any of the stuff I was interested in on top of it, I probably wouldn't have written Blobcache.
Trusting a server to store an application's state is a different thing from trusting it to author changes or to read the data.
Servers should become dumber, and clients should become smarter.
When I use an app, I want the app to load E2E encrypted state from storage (possibly on another machine, possibly not owned by me) make whatever changes and produce new encrypted data to send back to the server.
The server should just be trusted for durability, and to prevent unauthorized access, but not to tell the truth about doing either of those things.
Blobcache provides an API to facilitate transactions on E2EE state between a dumb storage server and any smart client.
Blobcache can be installed on old hardware along with a VPN like Tailscale and then loaded up with data from other devices.
Configuration is like SSH, drop a key in a configuration file to grant access.
It removes most of the friction associated with consuming and producing storage as a resource.
I'm using it to build E2EE version control like Git, but for your whole home directory.
Blobcache is content addressed storage, available over the network.
Blobcache allow nodes to securely produce and consume storage.
Configuration in similar to SSH, drop a public key in the configuration, and you're done.
Blobcache is a universal backend for E2E encrypted applications.
Got is like Git, if you fixed all the problems with storing large files and directories in Git.
There's no "large files provider" to configure separately.
All the data for a commit goes to the same place.
Got also encrypts all the data you put in it, E2E.
If you've run into problems putting your whole home directory in Git, you might have more luck with Got.
Both projects are GPL licensed, FOSS. Contributions welcome.
https://github.com/brendoncarroll/nnc
I use it for running agents locally.
You can make your own presets (which nnc looks for in ~/.config/nnc/presets) or use one from the standard library
https://github.com/brendoncarroll/nnc/tree/master/presets
Presets are written in Jsonnet, and resolve to a list of things to pass through from the parent process into the container. Presets can reference other presets, so you can build up arbitrary rules for passing files and devices into containers, give those rules a name, and reference them later.