It definitely solves problems when traveling and dealing with crappy airport/hotel/AirBnB/conference wifi that is slow or overloaded.

I also enjoy the ability to quickly launch/manage Digital Ocean instances useful sometimes as well.

Not leaving pull requests for over half a decade fixing critical issues with not even bothering to comment on them would probably be a massive advantage over Mosh.

one thing to consider though is how a large download over an ssh tunnel effectively prevents any other connection through the same tunnel from working.

to fix that possibly sshuttle can provide some inspiration. they solved that problem.

sshfs may be tricky, because it could lead to locked/hanging file access that never comes back if the server goes away. i don't know what the best approach here is. maybe some sort of timeouts, or maybe do let it hang but provide diagnostics with a command that can tell you what the status of the mount is, and force an unmount or restart of the connection if the user knows that the server went away.

aside from that it would just be nice if i would not have to manually remount every time the ssh connection drops.

another feature that i wish mosh had is to be able to reconnect to an existing session even with a restarted client. i don't know what it takes to do that. perhaps you need to store the keys that were used last time on disk which could lead to some concerns, but maybe that file on disk can be protected, or maybe that is not even necessary. i can attach to an existing tmux session, so if the mosh session is treated like that, it would work too?

But I don't know how widespread that is.

Mosh is a lifesaver

1. There was no scroll-back so you could only see 1 terminal screen of output. If you scrolled back, the text would be wrong or truncated or something like that. We would work around this by launching a tmux session and using that for scroll-back, but tmux scroll-back over a remote connection is so much clunkier than scrolling back in your local terminal emulator. If I'm already launching a tmux session, then I don't need mosh's ability to recover from broken connections because I can re-attach to tmux.

2. I found the typing prediction to be more annoying than it is worth. It worked great in bash but interactive apps (like those based on ncurses), the app would often end up a distorted mess until the round-trip to the server got back the real/correct rendering from the server. If I'm waiting for a round-trip from the server then I'm not getting any benefit from mosh's predictive typing.

3. It was only a remote terminal replacement. If you're doing anything more over ssh (port forwards, x11 forwarding, etc) then you're going to run into all the normal ssh issues anyway.

4. You had to run a 3rd party script to kill old abandoned mosh sessions. This is a consequence of being able to re-attach after a broken connection: the mosh server has no idea if you're coming back or not, so it leaves your session there. At least with tmux I can list the active sessions, re-attach to them, see what they're doing, and destroy them at will. With mosh, you could only reconnect to an old session if you hadn't closed mosh on your laptop. If your laptop powered off (intentionally or not) then you could either play "guess which mosh pid to kill" or leave your mosh session running long enough for the mosh killer script to get it.

Also there was the issue of popularity/network effects. ssh is everywhere, mosh is not, and its hard to argue that mosh should be everywhere when I was getting only slight benefit from it. This isn't mosh's fault, any ssh competitor that isn't upstreamed into openssh is going to run into the same exact problem.

With my hypothetical ssh-over-QUIC I'm hoping for just plain-old ssh with all the normal features, just using QUIC instead of TCP. Ideally upstreaming into openssh. I know there are a bunch of projects out there attempting something like ssh-over-QUIC but I think it has to be upstreamed and a drop-in replacement to overcome the popularity moat regular ssh has built.