3 ms·

There's work happening in that direction: https://discourse.nixos.org/t/obsidian-systems-is-excited-to-bring-ipfs-support-to-nix/7375 https://discourse.nixos.or

There's work happening in that direction: https://discourse.nixos.org/t/obsidian-systems-is-excited-to-bring-ipfs-support-to-nix/7375 https://discourse.nixos.org/t/obsidian-systems-is-excited-to... 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.

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 ago
  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?
  - Ericson2314 3y ago
    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. It's good question :)

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 ago
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?
- Ericson2314 3y ago
  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. It's good question :)