This is to gauge community interest and help in pursuing the implementation of a peer-to-peer binary cache system for Nix, following a recommendation to do so.
While decentralised, self-sustainable technology is a dream for many, it is good advice to evaluate whether the idea is necessary or realistic in order to invest oneself to a large task.
We don’t know for sure how many people are willing to use the work, and it may be that the foundation is able to continually secure sponsorships and donations such that decentralisation becomes meaningless.
Disclaimer: I don’t have intimate knowledge of Nix/BitTorrent internals and in no way am I a security expert.
The idea is to shoehorn BitTorrent (if feasible at all) as a binary cache substituter: leechers query store paths on-demand to the swarm, in order to reduce the risk of leaking private derivation data, as attackers would have to bruteforce the private hash + derivation name & version.
Seeders easily opt into the swarm thanks to a new
services.nix-serve-p2p.enable: bool = false Nix option enabling a service to join the swarm. This could be added as a comment in the generated config to raise awareness and help it more easily gain traction.
services.nix-serve-p2p.max-upload-speed allows users to decide how much bandwidth they wish to contribute.
To prevent further attacks, rate limit failed queries by determining if the path isn’t publicly known using the union of public
store-paths.xz files from registered HTTP substituters.
nix.settings.substituters.?.public: bool = false option could be added to distinguish public vs private substituters, https://cache.nixos.org/ being public.
A possible extra paranoid step would be to add a
private: bool = false per-package option to ensure derivations stay private at all costs. The resulting store path would become a dotfile to easily filter them out in the above rate limiting system.