Hi @Ericson2314, I have a few questions about the implementaion that you may be able to clear up.
-
Is the intent that a significant portion of of Nix installations would also have an IPFS daemon running alongside to provide IPFS connectivity?
-
Is there any provision in the current roadmap to allow substitution via an IPFS gateway such as the cloudflare gateway?
-
When running an IPFS daemon and pushing nix store paths into IPFS, is the path added with --nocopy (filestore backed) or are the contents duplicated into ipfs chunk storage? Is this why the store path gets a nix temporary GC root?
-
When substituting paths from IPFS, are the paths fetched to the ipfs filestore and symlinked/hardlinked into the nix store? Would this create a ipfs pin to prevent cleanup from IPFS?
-
Regarding the following statement:
Trustless remote building: Nix users shouldn’t need to be trusted to utilize remote builders.
The way I currently understand building with nixpkgs, most derivations are built by a trusted source (hydra) and only packages you’re customizing or developing yourself need to be built locally or a remote builder. For these packages, you don’t know what the result CID will be until you’ve built it for the first time, and if you’ve built it to get the CID, you no longer need a remote builder to do the build for you.
Is my understanding here wrong, or am I missing some use-case that makes trust-less remote building more useful?