Those of us who are interested in DVMs for CI on nostr should start collaborating.
nostr:npub1hw6amg8p24ne08c9gdq8hhpqx0t0pwanpae9z25crn7m9uy7yarse465gr nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc
eg. building artifacts, running tests and deploying code.
there is an open invitation - comment on this note and we will loop you in
I'm in! nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 will be interested too I'm sure
🤝🔥🤠
#nostrCI
P.s. I have the meme for this. ETA 5 hours
Let’s do it
yo im curious, been thinking about a nix builder and cache. loop me in?
Definitely. I'm interested. Tell me more?
basically want to create a 'nostrpkgs' like nixpkgs, so a set of recipes for how to build git repos, but we also want to serve the binaries. Advantages would be reproducible builds, cross-platform outputs, language-agnostic, and anybody could standup a cache and broadcast build events.
Re: DVM, this would be "i have a build recipe, plz build me this output and give me a url to fetch it from"
I like it. Who would control what packages made the cut? You could run a blossom server and store the binaries on using that to add resilience.
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.
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.
nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p is interested in this too
There is a project called nostrCI that nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5
presented on in riga. its about interoperability across nostr clients and there is a overlap with CI on nostr. There is a signal group for it and a call happening at 1430 UTC. If you want to join the singal group or the call, please shout up.
nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc nostr:npub19w6s06qgvfy8glfwc5qf5uxvm0staycslfsjj55j8jzhned2spzq8psyzj nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p nostr:npub1ecdlntvjzexlyfale2egzvvncc8tgqsaxkl5hw7xlgjv2cxs705s9qs735
There will be a call to discuss next steps on creating DVMs for CI on Tuesday 1500-1600 UTC. All welcome. This one will be on Signal. https://signal.group/#CjQKIKJiex5Jw2qDiV9QjJ7zVSGoNG5kCH9XUhdq4r4QVYsuEhDFFZuW9SDMgC7N3QDpL4QF
FYI nostr:npub19w6s06qgvfy8glfwc5qf5uxvm0staycslfsjj55j8jzhned2spzq8psyzj nostr:npub1yay8e9sqk94jfgdlkpgeelj2t5ddsj2eu0xwt4kh4xw5ses2rauqnstrdv nostr:npub1ecdlntvjzexlyfale2egzvvncc8tgqsaxkl5hw7xlgjv2cxs705s9qs735 nostr:npub1q6ya7kz84rfnw6yjmg5kyttuplwpauv43a9ug3cajztx4g0v48eqhtt3sh
Thanks everyone. We had a productive call today to discussion where we were all coming from and I'm looking forward to see what progress we can make. nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc pointed us to his project https://dvmdash.live which I think will be a super helpful resource in our journey.
