4 ms·
See https://github.com/NixOS/hydra/issues/838 https://github.com/NixOS/hydra/issues/838 for making content-addressed derivations supported by hydra.nixos.org. A
by Ericson2314 3y ago
See https://github.com/NixOS/hydra/issues/838 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.
Also see https://github.com/NixOS/nix/issues/8919 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 :).
- voidmain 3y agoCouldn'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?
- Ericson2314 3y agoYes 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. It's good question :)