| 19 Jan 2026 |
 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 |
| Mic92 | I maintain two binary caches that were implemented from scratch. It's not much work if you just want to validate a concept, proxies can be quiet easy. So if you want to move fast, just doing it from scratch might very doable. If you have to handle storage i.e. garbage collection, things get trickier. | 15:28:44 |
| Robert Hensing (roberth) | The responsibility of the team is to guide the discussion as long as it is constructive, new points are brought up and the RFC is iterated on and from time to time summarise the current state of discussion. If this is the case no longer, then the Shepherd Team shall step in with a motion for FCP. | 15:29:05 |
| Mic92 | If you don't care about too many feature, you can get a way with two http calls for narinfo and nar and a static one for narinfo | 15:29:59 |
| Mic92 | That's the theory, but in practice it's feels quiet overwhelming to having to respond to so many people. | 15:30:51 |
