| 9 Apr 2026 |
 emily | picking the .drv out of temproots is my current best guess | 23:13:42 |
|  Lisanna changed their profile picture. | 23:14:48 |
 Neil Mayhew | OK, that makes sense. There's no point in trying to make cachix use the lix-store library. However, what would happen if I use the current cachix (linked with nix-store) on a system that's using Lix as the nix-daemon? Would that break too? | 23:48:58 |
| 10 Apr 2026 |
 kfiz | Maybe, I only just learned that lix-daemon is only compatible with v1.35 of the nix-daemon protocol. If cachix relies on newer features this might break. | 00:47:26 |
| Neil Mayhew | Thanks, that's helpful and gives me something concrete to check | 00:48:30 |
| kfiz | Your welcome. see link to source from an earlier post. | 00:51:57 |
| Lisanna | If you're planning anything in the remote builder space, I'd be very interested to know btw ^^ I've been doing work on improving remote building in cppnix so always interested in seeing what other use cases people have | 01:33:59 |
| Lisanna | also, if y'all would like any help on that effort, I definitely have the time, unless you think it would be harder to split the work | 01:41:57 |
 raitobezarius | In reply to @emilazy:matrix.org
what's the current most least uncursed way of going from a build's PID/UID to the .drv it's building? What nix-top does: look into /nix/var/nix/builds and then peek at env-vars outPath I'd say | 04:25:37 |
 K900 | No, it should be fine | 05:45:46 |
 phaer | There's a third rust implementation of it in harmonia, https://github.com/nix-community/harmonia/blob/main/harmonia-daemon/README.md. | 08:23:36 |
 Yureka (she/her) | that implements the other side | 08:27:43 |
| emily | so UID -> owner of build dir -> envs?
that var could be overridden by an evil derivation though right?
| 10:35:21 |
| emily | it feels a bit less robust than the temproots route to me | 10:36:08 |
| raitobezarius | cannot remember right away if an evil derivation can edit outPath, if security against malicious derivations is important, yeah, that's not ideal | 11:05:43 |
| emily | it's "workload attestation at home" | 11:11:33 |
| emily | so would at least be nice | 11:11:52 |
| emily | do you see any problems with the temproots approach? I suppose there's no strict guarantee that the files are named after the nix-daemon PIDs or that they don't have random other derivations in there that can't be reliably distinguished? | 11:13:02 |
| raitobezarius | i don't see problems with temproots approach immediately | 11:14:52 |
| raitobezarius | for nix derivations? | 11:14:56 |
| raitobezarius | i so want to add the goddamn API in the daemon so you can get workload proofs proper | 11:15:17 |
| raitobezarius | well, there can be temproots for other things appearing | 11:15:45 |
| raitobezarius | it's not a 1:1 mapping with derivations being built | 11:15:50 |
| emily | yeah. ofc a proper story would be great but I'll take what I can get for now | 11:16:11 |
| raitobezarius | i think temproots is probably the best | 11:16:21 |
| emily | the ones for builds are named after the daemon PID | 11:16:25 |
| emily | so the lookup is easy there | 11:16:34 |
| raitobezarius | but there's multiple subdaemons PIDs | 11:16:37 |
| raitobezarius | i would also go for the dangerous scenario for a PoC | 11:16:40 |
| raitobezarius | for a intermediate production level target, i'd do a proxy nix daemon real quick | 11:16:49 |
