| 13 Mar 2026 |
 raitobezarius | We're not going to use gRPC in Lix | 13:44:02 |
| raitobezarius | We're using already Cap'n'Proto | 13:44:07 |
 Lisanna | Ah, OK, I must have confused them | 13:44:21 |
| raitobezarius | https://git.lix.systems/lix-project/lix/src/commit/5346b2bc6884ab71c1d0fc858f3b11484d01cbfb/lix/libstore/build/hook-instance.capnp | 13:44:36 |
| Lisanna | ok, so I' | 13:45:22 |
| Lisanna | * ok, so I'll rephrase then :p are there plans to extend capn proto to the daemon? Has that already started? | 13:45:41 |
| raitobezarius | This is going to start imminently in 2.96 | 13:45:52 |
| raitobezarius | Lix 2.94 made hook instance capnp | 13:45:57 |
| raitobezarius | Lix 2.95 used Cap'n'Proto for exchanging settings between libexec helpers and the daemon | 13:46:07 |
| raitobezarius | Lix 2.96 will offer daemon sockets with multi protocol support | 13:46:21 |
| raitobezarius | Lix 2.95 already has the inherent capability | 13:46:27 |
| raitobezarius | https://gerrit.lix.systems/c/lix/+/4951 | 13:46:36 |
| Lisanna | ok, thank you! | 13:47:51 |
 hexa | sad that you'll be spending time for cppnix instead of lix then 😉 | 14:18:26 |
 piegames | That's not the sad thing, we're not doing software tribalism here. The sad thing is the usage of gRPC, which isn't the best technical option, and also will make CppNix and Lix fairly daemon-incompatible long-term | 14:41:54 |
| piegames | IIRC snix is using gRPC, and it wasn't going too well for them? | 14:42:13 |
 flokli | we're using gRPC if you cross the process boundary | 14:42:50 |
| flokli | and it's working fine-ish? | 14:42:55 |
| piegames | Or am I misremembering something here | 14:43:02 |
| flokli | there's a few known perf issues due to how to the blob/chunk substitution doing more roundtrips than necessary, but that's more of a "we need to refactor the code at some point" than a gRPC-issue per se | 14:44:00 |
 griff | And as long as the data flowing is compatible making a converter from gRPC to Capnp or even to old shitty daemon protocol should be possible | 14:45:51 |
| flokli | we picked gRPC over captnproto because it's generally better supported across various programming languages, and it felt like captnproto still requires you to be on your own for a lot of things. | 14:45:54 |
| flokli | That being said, it's just another implementation of our traits, you can also talk another protocol. | 14:46:14 |
| flokli | I don't know how much captnproto forces you to model your application logic to its needs, if you make use of some of the more fancy stuff. We don't use any of these currently. | 14:47:05 |
| griff | it doesn't force your application logic to do anything. gRPC does that more in that it is entirely request/response based and you can't send an interface to be called back to the remote | 14:52:23 |
| flokli | ok, what i meant to say is that right now all our traits are request/response based. | 14:55:25 |
| flokli | so using either captnproto or grpc is just a matter of implementing that trait surface. | 14:56:13 |
| Lisanna | I was mixing up gRPC with Capn Proto, the only reason I mentioned gRPC is because that's what I thought Lix was going with | 14:58:37 |
| Lisanna | we may not touch the protocol implementation at all and instead focus on providing an extensible API in libnix-store | 14:59:23 |
| piegames | Ah | 15:00:02 |
