| 22 Apr 2025 |
 helle (just a stray cat girl) | yeah, that was the cases we weren't sure about | 13:30:23 |
 K900 | Without breaking people | 13:30:27 |
| K900 | So we'd need ssh-ng-ng or something | 13:30:34 |
| helle (just a stray cat girl) | hold on | 13:30:59 |
| K900 | And I feel like this might be easier to land after the protocol rework | 13:31:16 |
| helle (just a stray cat girl) | there is a weird ssh option/idea we have seen that needs a quick check | 13:31:17 |
| helle (just a stray cat girl) | In reply to @k900:0upti.me
And I feel like this might be easier to land after the protocol rework definitely | 13:31:27 |
| K900 | Because among other things the new protocol has a hello message | 13:31:29 |
| helle (just a stray cat girl) | yeah, but uh, goal of "everything runs via the daemon (or more accurately, with only a single command ever executed on the remote server directly via ssh" seems like an important thing
and optionally "we can open our own channel, with a single command that we run remotely giving us the path to the unix socket for this" (this may require libssh, don't recall if ssh can dynamically setup forwards, but doubt it) | 13:38:30 |
| K900 | We can set up a socket on our end | 13:38:45 |
| K900 | And then pass it to the command | 13:38:53 |
| K900 | We do need command line args to at least SOMEWHAT work | 13:39:02 |
| helle (just a stray cat girl) | the socket name we need is on the remote machine | 13:39:42 |
| K900 | Not if we do it backwards | 13:40:04 |
| helle (just a stray cat girl) | mmm, what are you thinking of in terms of the steps that would execute? | 13:40:25 |
| K900 | Literally we just forward the socket in the other direction | 13:40:44 |
| K900 | And have the remote end connect to it | 13:40:52 |
| helle (just a stray cat girl) | but then we need to be able to tell the remote end what unix socket to connect to and not entirely sure this is fully implemented in libssh (with the problem of also in that way round, the cleanup is not well handled, sshd will create the socket file, but will not clean it up) | 13:51:09 |
| helle (just a stray cat girl) | we think stdio may be fine, if we can deal with a shell outputting stuff before our protocol is up, scp does this, sftp would also be doing this, except everyone seems to use internal-sftp, which uh, never hits the shell...... | 13:54:11 |
| helle (just a stray cat girl) | the "connect to a unix socket on the remote machine and make it available as a channel on the local one" is well supported in libssh iirc | 13:55:50 |
| K900 | https://buildkite.com/lix-project/lix/builds/1199#01965dbc-7113-43ad-a1f7-41c6ca232cd5 | 13:59:26 |
| K900 | You what | 13:59:27 |
| K900 | Wait wait wait wait WHAT | 14:02:01 |
| K900 | No | 14:02:03 |
| K900 | FUck | 14:02:08 |
 KFears (burning out) | In reply to @k900:0upti.me
Yes but we can't replace the existing protocols with "just talk to the daemon" because there may be no daemon Speaking of, can we get like a wiki page or a pad for this? I don't understand at all what's the difference between daemon single-user and daemonless and how does daemonless work at all, it's very unintuitive | 14:27:05 |
| helle (just a stray cat girl) | (ooof, my ssh test case for subsystems is currently broken, and it has been a while since we worked with that) | 14:45:51 |
| helle (just a stray cat girl) | also someone needs to document yeah, the existing protocols, because clearly we did not catch some of the edge cases | 14:46:09 |
| K900 | OK so some updates | 15:39:37 |
| K900 | Me and horrors came up with some exceptionally cursed fuckery | 15:39:48 |
