Closed God-damnit-all closed 4 years ago
We're not going to implement literal mosh support, however, we have a multiplexing feature that is equivalent to using mosh+tmux but with native tabs and windows:
https://wezfurlong.org/wezterm/multiplexing.html
It needs a bit more polish still, but that's where the effort for this feature set is going to go.
(I think this request is in the wrong repo? Should be in wezterm?)
Oh, woops, sorry, you're right. How about I close this and make an issue there about UDP support for the multiplexing feature?
FWIW, UDP on its own isn't the killer feature of mosh: it's the predictive local echo combined with the transparent "reconnection" when migrating across networks that make it feel good.
The TLS multiplexing in wezterm has worked well for me as a mosh replacement for the past several months at work (where we have the PKI infrastructure that makes it easy to configure), but is sensitive to east-west coast latency for a colleague.
If you do open an issue against wezterm for this, it would be preferable to focus on the experience rather than the implementation details, as just using UDP on its own trades away the security and reliability that we get for for free from TLS and SSH transports, and requires a custom stack to fill its place which introduces a lot of additional complexity... and it doesn't guarantee that the experience will actually be better.
mosh is a drop-in replacement for ssh that makes up for some of the protocol's weaknesses by taking advantage of UDP. It's able to do 256 colors and redraws the console at a much smoother and faster rate.
Unfortunately, it's kind of a pain in the ass even for Linux to get working right, as the project has been dragging their feet about actually pushing a release, all while the dependencies it uses are becoming deprecated on modern Linux distros, which is why it's now built into some shells like Android's Termux.
As for Windows, it's the only OS that never got a native version. Someone forked it and came close, but the project leads didn't seem interested in supporting it and it died on the vine. And using it through WSL seems to lead to a lot of very small issues that are very hard to troubleshoot, and given how inactive the project is now, it's not likely to ever work entirely correctly. (They advertise a chrome version, which does have a dev branch, but this seemed to have even more issues).
It is, in all likelihood, going to be necessary to integrate it into a Windows shell if it's ever going to work completely correctly, and given this project seems to be the only actively developed Windows shell that isn't trying to operate off 'reverse engineering' (for lack of a better term) the Linux kernel, I thought I might ask here.