Thanks, the goal would be to get a complete a set of nostr tools, so as little gatekeeping as possible ideally. Will think it thru further. idk if this fits with what yall are doing.
Discussion
Definitely. nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 and I both have immediate usecases for a DVM that runs CI to build artifacts (for nostr:npub10r8xl2njyepcw2zwv3a6dyufj4e4ajx86hz6v4ehu4gnpupxxp7stjt2p8) and lint, tests etc (for #GitViaNostr). We were thinking that may projects have github actions and there is an open source GitLab CI runner that github actions so that could be a good place to start.
Then we met nostr:npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr who was also interested in this and nostr:npub1grxpu52m4w7gm9amdj8h847qjpxcmekha60ent28slxm74487mcqmm87js who is interested in DVM more generally.
Now you are up to speed on the context!
Tysm!!
As a nix user, and as a maintainer of a project that needs binaries installed, I'm also more broadly interested in your idea. This is on top of the obvious overlap of A DVM that builds binaries.
I often build binaries from source. Wouldn't it be cool if, whenever I built a binary from a reproducible build, I could elect to easily publish to say that I validated that the commid-id / version tag produced a binary with the correct check sum, or not via nostr?
Bingo! Its also cool with Nix because whenever you have a derivation where the output hash is deterministic, it can just ask the cache's nostr bot if it has the hash in its store, and you know you're getting the binary you expect, as if built locally.
but if you don't build yourself, you are trusting whoever has given you the hash. getting trust assertions from a verity of sources that a version should produce that hash means that you are drastically reducing your trust in any one source.
more sources is better for sure, but the first sentence isnt necessarily true. How Nix works is the derivation has the output hash before its built. If i evaluate the build recipe and get a derivation output hash, i can then query a remote cache for that build hash.
Nix the package manager will check if the received binary matches what we expected. So youre trusting your own eval of the build, but getting the remote binary for it. Pretty neat imo.
Cool project in this vein https://nix-community.github.io/trustix/
but how do you get the derivation output hash from the build recipe?
thats a cool project. thats exactly what I was talking about with different peers doing the build and reporting back that they got the same hash. These could be nostr trust attestation events.
nix-instantiate https://nix.dev/manual/nix/2.18/command-ref/nix-instantiate
so `nix-instantiate` gives the hash of the derivation and `nix-store --realise` produces the hash of the actual binary output?
close, instantiate creates the derivation (which specifies an output hash). `nix-store --realise` builds it, producing a binary (a store path).
in the first example they use I'm guessing cigxbmvy6dzix98dxxh9b6shg7ar5bvs is the derivation hash and qhqk4n8ci095g3sdp93x7rgwyh9rdvgk is the output (binary) hash. Is that right?
In which case the derivation doesn't include the output hash or am I missing something?
https://nix.dev/manual/nix/2.18/command-ref/nix-instantiate#examples
```
nix-instantiate test.nix (instantiate)
/nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv
nix-store --realise $(nix-instantiate test.nix) (build)
...
/nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26 (output path)
ls -l /nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26
```
try `nix derivation show /nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv`
it will have an outputPath field with the binary hash. A derivation is just a json-like blob.
apparently it is not a valid store path
Ah yea its an example i guess. You could try any nix package you have defined locally, or further in the examples theres: `nix-instantiate '
yes that worked. but aren't we trusting that the author of the derivation is not including a malicious hash? this is what trustix was trying to solve or an I still missing something?
A derivation isnt downloaded, its generated locally. Then you take the output hash of the generated derivation, and look for it first locally, then remotely at binary caches. The point is that a deterministic build can be defined (the outputHash) locally and fetched remotely without fear, nix will check the received binary. Its why we call caches "substituters" in Nix, bc i can safely substitute a build output with a remote one if i know its hash. I should draw this out 😅
Trustix is more about detecting malicious builders at large. If you only rely on caches for your packages, we can compare their build outputs to each other and generate trust scores over time. It would need an ecosystem of builders to be useful.