Cloudflare R2-Backed Nix Binary Cache on Fly.io
lgug2z.com
lgug2z.com
Though to be fair, there is no reason that experimental features cannot depend on other experimental features.
My impression is that although nix makes it easier to achieve repeatable builds, not all nix builds are repeatable. It takes some diligence on the part of the package author as well.
Switching nix from an inputs-addressed model to a content addressed one may shine a light on this, which will be nice for discovering the hidden variables which contribute to nondeterminism, but might come with its own headaches re: "why do I get a different hash than expected? Is it broken?"
I'm still excited to see it happen, but I think there's a certain crowd who might be disappointed that it's not as magical as they envisioned it.
Also see https://github.com/NixOS/nix/issues/8919 for this accepted RFC
Once those things are done, we can get back to merging in the IPFS code.
Now that there is an Nix team and I am on it, there is much, much less of an issue of these experiments being caught in limbo :).
In principle, signatures also address the cache itself being untrustworthy, right?
However, I haven't pursued unbundling them so much:
1. A big use-case is right now cache.nixos.org is too big and the old sponsor for hosting dropped.
2. CA derivations have the potential to greatly reduce new store object churn because they normalize derivation outputs more strongly (two different derivations producing the same result now results in the same store object, not a different one.)
If someone were to say "no, we needs IPFS right away, please help" I would do that, but no one said so yet.
It's good question :)
That means that the only way to validate the contents would be to take all the inputs and build the derivation yourself, defeating the purpose of using the cache. That means that nix caches must be trusted to not be malicious, with no computationally efficient way to protect against cache poisoning.
There is a project underway to transition the nix store to be content addressable, which will decouple trust from distribution.
I always had the impression that derivations being content addressable was one of Nix' main selling points. For reproducibility etc.
The father I dive into Nix, the more I get the feeling that nixpkgs is only half of a package manager; and that the other half has been perpetually put on hold, while we wait for the eventual perfect implementation of Nix to make that half implicitly obsolete.
The more I use Nix (especially NixOS), the more I feel like that second half of the package manager is precisely what I am missing. Even when it it's obsoleted by guaranteed reproduciblity, I may still find value in it.
I would love to have a nix store that accommodates traditional gpg-signed packages. The usefulness of that would extend beyond Nix and nixpkgs.
Derivations can be signed already, and are signed in the official cache I believe. You can configure which keys to trust.
In that sense, it think it is possible to mirror the official cache.
derivations are always content-addressed.
derivations outputs can be input-addressed or content-addressed, but the latter is still an experimental feature.
R2 is an Amazon S3-style object store.
D1 is a Javascript/HTTP API to access a hosted SQLite.