Something that's been itching at the back of my mind for a while: the nixpkgs binary cache is a perfect candidate for P2P. I wonder how hard it would be to put it on bittorrent.
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.
See https://github.com/NixOS/hydra/issues/838 for making content-addressed derivations supported by hydra.nixos.org. At that point, we can actually try out the XP feature at scale.
Couldn't you just continue to serve the tiny .narinfo files from a trusted central source while letting bittorrent or ipfs cache the .nar files (big, but can be validated by hash)? It doesn't allow for untrusted builds but it would work with all kinds of derivations.
In principle, signatures also address the cache itself being untrustworthy, right?
Yes we can, these things don't have to be bundled together.
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.
Nix derivations are not actually content addressable, at least not yet. Derivations are input addressed.
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.
When that work is done, will it be a strong enough guarantee to use instead of just gpg-signing derivations?
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.
