| 19 Jan 2026 |
 Robert Hensing (roberth) | maybe it's a cognitohazard and we should just ignore it for another year | 15:12:57 |
 raboof | yeah, performance-wise it's hard to predict the trade-off between the benefit of not needing to evaluate the first parameter vs the cost of delaying when it's needed after all - AFAICT infinisil's work seems to suggest it's not a huge benefit (if at all). | 15:13:54 |
 Taeer Bar-Yam | Also would this change solve anything for anyone or improve anything? I don’t think I’ve ever run into a situation that needed it, personally | 15:13:58 |
| Robert Hensing (roberth) | It could solve a portion of infinite recursions that necessitate lazyAttrsOf instead of attrsOf in module system use. Actually it might make that use case worse because definition merge order is deterministic but arbitrary in the module system. | 15:16:08 |
| Robert Hensing (roberth) | It would speed up nix-env -q because // { type = "derivation"; } could just be the last thing in every mkDerivation (or similar) call. | 15:16:58 |
 Mic92 | A different rabbit hole is improving narinfo lookup in our current binary cache protocol by adding an efficient index that can be downloaded (incrementally): https://github.com/NixOS/rfcs/pull/195 For now kalbasit is implementing this in his binary cache proxy. And I am planning on matching this with my binary cache implementations, but at some point it would be also useful for Nix to have something like this. Currently it's in concept stage and we want to test with some implementations how it performs. It would be the dream if we also had this in cache.nixos.org, but it would be also useful otherwise i.e. if you have many small scoped caches and don't want to reach out to each of them all the time. It unlocks features like efficient p2p binary caches. | 15:17:35 |
 magic_rb | exciting times | 15:18:08 |
| Robert Hensing (roberth) | If I were to shepherd that RFC I'd basically require cache.nixos.org integration before completing the RFC | 15:18:51 |
| Robert Hensing (roberth) | If it doesn't work for that (almost) what's the point | 15:19:01 |
| Robert Hensing (roberth) | * If it doesn't work for that what's the point (almost) | 15:19:55 |
| Mic92 | Not really, required. It doesn't even need to be accepted by the nix community as long as there are compatible implementations. | 15:19:57 |
| Mic92 | But it's nicer if everyone use the same standard of course | 15:20:29 |
| Mic92 | Right now cache.nixos.org is a rather big dataset that is hard to experiment with. | 15:22:14 |
| Robert Hensing (roberth) | It is the most worthwhile though | 15:22:32 |
| Robert Hensing (roberth) | Most worthwhile per byte even, I would argue ;) | 15:22:42 |
| Robert Hensing (roberth) | But do ignore me if I'm just a whiny bitch | 15:23:19 |
| Robert Hensing (roberth) | That is a very real possibility | 15:23:31 |
| Mic92 | Yeah a lot RFCs are suffering from feature creap. | 15:23:40 |
| Robert Hensing (roberth) | Maybe we need more version twos | 15:24:09 |
| Robert Hensing (roberth) | At least this is a relatively transient and optional thing where going to a v2 isn't all that painful. Just switch | 15:24:53 |
| Mic92 | As an RFCs author you are exposed to a multitude of opinions that can become noisy and contradict each other. | 15:25:04 |
| Mic92 | I sometimes have a feeling the are too many cooks. | 15:25:22 |
| raboof | Mic92: apropos binary cache proxies: at some point I want to build a binary cache proxy that does "fetch from upstream binary cache if there's a matching trusted independent rebuild attestation, otherwise rebuild myself". Any recommendations on whether I should base that on any existing cache proxy (which one?) or just keep it independent? It seems fairly simple (but that's famous last words :D ) | 15:25:30 |
| Robert Hensing (roberth) | Well, that's the point, right? You get all the opinions, and then you decide | 15:25:41 |
| Robert Hensing (roberth) | It creates a well-informed decision | 15:25:56 |
| Mic92 | Well the problem is that you it's hard to decide which opinions you have to ignored. | 15:26:12 |
| Mic92 | * Well the problem is that you it's hard to decide which opinions you have to ignore. | 15:26:17 |
| Robert Hensing (roberth) | That is also something an RFC author should be able to decide IMO. With shepherds I guess | 15:26:58 |
| raboof | * Mic92: apropos binary cache proxies: at some point I want to build a binary cache proxy that does "fetch from upstream binary cache if there's a matching trusted independent rebuild attestation, otherwise let/force me to rebuild myself". Any recommendations on whether I should base that on any existing cache proxy (which one?) or just keep it independent? It seems fairly simple (but that's famous last words :D ) | 15:28:04 |
| Robert Hensing (roberth) | Shepherd Team
A team of 3-4 community members defined unanimously by the RFC Steering Committee, responsible for accepting or rejecting a specific RFC. | 15:28:38 |
