It occurs to me that the time is ripe for a wholesale rethink of the system constructed from terminal-window-SSH-shell-computer. Loosely called shell or SSH but actually a different beast.
Back in the old days, the new fangled "terminal" was typically a small computer that would do a "screen" which was a small program that would capture all the details needed for order-entry on a keyboard and TV display. Once the person was finished and sanity checking was good, the EXECUTE button would be hit and the terminal would package up the entire page and send it to the mainframe for processing.
Then, came Unix and the command line interface, in which the user hit a button, it was sent across the copper directly to a program called "the shell" which then echoed the charactert back to the terminal. The terminal only displayed echoed characters, so you know when characters weren't getting through. Copper was so fast that this was more or less real time, and it gave you the impression that you were "on the computer."
The next innovation was the net, and briefly telnet became the rage until passwords got snaffled, so it was replaced with SSH. Which worked and worked well (go figure...). Later on, someone realised that the protocol was really a datagram mishmash and we got mosh.
But SSH and mosh were still preserving the whole character-by-character experience. Because the shell, ya know? When in practice what we are doing on command line shells is preparing "lines". Which look very much like the screens of the old days. So it seems the time is ripe to stop treating this as a system of components and go back to the holistic design of screen-based terminals.
We need a system that splits the shell into client-side and server-side, absorbs the privilege separation issues naturally, has an inbuilt secure crypto protocol based on mosh or QUIC that is internal, not some library cruft that is grafted on with chewing gum and string, and feels more like an IDE or editor ... I prepare the command in a context-aware full page screen, which checks it as it is going for syntax (and hopefully semantics later on) and then submits the page across to its on-server counterparty for further checking and execution.
I suspect ... once we get away from the character monkey on our backs, this old old notion will open up a lot of new thinking about driving servers.
But it's a big project - one needs to understand Unix, shells, SSH, mosh, modern datagram programming, UIs, IDEs, privilege separation. And there's at least a year's coding in C++ (sorry), after all the research. Possibly a research project for a grad level student? Open source - if you like it, propose it to your prof and get stuck in. Or, if someone's already on it, let us know in comments!
