| 13 Mar 2026 |
 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 |
| Lisanna | honestly I could be tempted away from cppnix into Lix dev, I <3 Lix but right now I'm trying to get a job working on Nix so cppnix is where I'm spending my free time to try to maximize hirability ): | 15:06:01 |
 raitobezarius | i think the biggest annoyance about gRPC is that it mandates HTTP2 on the wire and it's so annoying | 15:06:52 |
| raitobezarius | like gRPC over stdout/stdin is not a thing | 15:06:57 |
| raitobezarius | if we had used gRPC, we would have needed to do crimes to implement what we did with libexec | 15:07:15 |
| raitobezarius | capnp is way more behaved in that regards | 15:07:38 |
| raitobezarius | you might be mixing up this with arcana | 15:09:03 |
| raitobezarius | or even god forbids: gRPC over socketpair() | 15:10:24 |
| griff | how are you going to do capnp remote? ssh, mTLS? | 15:11:21 |
| raitobezarius | mTLS with the possibility to reuse SSH authnz | 15:11:32 |
| raitobezarius | aka SSH as an authorization hook | 15:11:47 |
| raitobezarius | SSH for the data channel seems a dead end tbh | 15:11:57 |
| griff | why? | 15:12:25 |
| Lisanna | * honestly I could eventually be tempted away from cppnix into Lix dev, I <3 Lix but right now I'm trying to get a job working on Nix so cppnix is where I'm spending my free time to try to maximize hirability ): | 15:12:51 |
| raitobezarius | There's the performance problems of what SSH was optimized to do (TCP_NODELAY related topics) | 15:13:03 |
| raitobezarius | There's the "use libssh if you want to have control over the thing like readiness, etc." but "if you use libssh, you lose all the advanced openssh features" | 15:13:22 |
| raitobezarius | Maybe in Rust-land, we can use a proper config parser and have feature parity with openssh but people do depend on the exact details of openssh configs and this limits our ability to do better than an execve of ssh | 15:13:50 |
| raitobezarius | (execve of ssh is also not a great way to run a wire remotely) | 15:14:00 |
| raitobezarius | So, if we could bring this down to SSH is only used to authorize your mTLS connection, that'd give users the convenience of SSH key distribution/authentication while having a somewhat performant data channel (H2) | 15:14:40 |
| flokli | In reply to @raitobezarius:matrix.org
i think the biggest annoyance about gRPC is that it mandates HTTP2 on the wire and it's so annoying Hey, it could be worse. Like varlink over the network. | 15:17:42 |
| raitobezarius | let's not talk about varlink | 15:17:54 |
| flokli | Oh wait | 15:18:02 |
