NeoShell Note
neosh vs Mosh for Mobile Terminal Sessions
Should a mobile terminal use Mosh, neosh, or SSH with tmux when the network keeps changing?
Mosh optimizes a roaming remote terminal with local prediction, while neosh gives NeoShell an explicit QUIC session that can detach and resume after the current connection is gone.
Short answer
Mosh and neosh both start from the observation that a mobile terminal should not behave like one fragile TCP connection. They do not solve that problem in the same way.
Mosh synchronizes terminal screen state over UDP, supports IP roaming, and predicts common editing actions locally. neosh is NeoShell's QUIC-based transport with an explicit server-side session identity, detach behavior, and resume path.
The layers are different
Plain SSH carries a byte stream over one TCP connection. Mosh replaces the interactive SSH terminal after using SSH to start mosh-server. neosh also uses SSH bootstrap, then opens a QUIC transport to neoshd and authenticates the resumable session against the fingerprint returned by bootstrap.
tmux and zellij sit above all of these transports. They keep panes, processes, and a named workspace alive on the host even when no terminal client is attached.
| Topic | Plain SSH | Mosh | neosh |
|---|---|---|---|
| Bootstrap | SSH authentication opens the terminal directly | SSH starts mosh-server, then the client changes transport | SSH locates and starts neoshd, then hands trust to QUIC |
| Interactive data | TCP byte stream | UDP screen-state synchronization with local prediction | QUIC streams with explicit session control |
| Network change | Usually reconnect to the host | Roams between IP addresses while the Mosh session remains available | Reconnect and send RESUME for the stored neosh session |
| Session identity | Normally tied to the live connection | Maintained by the Mosh client/server session | Stored session id and resume token with server-side timeout |
| Files | SFTP can share the SSH connection | Terminal transport; file workflow is separate | NeoShell's neosh transport is terminal-only; use standard SSH for SFTP |
| Latency model | Input waits on network round trips | Predictive local echo targets high-latency links | No Mosh-style local prediction; focuses on exact session recovery |
Where Mosh is stronger
Mosh is the established choice when the main pain is latency, temporary packet loss, or changing IP addresses. Its client predicts common line-editing operations and reconciles them with the server, which can make typing feel local on a distant or inconsistent link.
Its official model requires Mosh on both sides and UDP reachability. The session can survive a client changing networks or sleeping, but Mosh is still not a host workspace manager; tmux or zellij remains useful when processes and panes must survive independently.
Where neosh is different
neosh is designed around an explicit terminal-session lifecycle. NeoShell records the session id and resume token, disconnects the current client without necessarily ending the server session, and can reauthenticate before resuming that same session later.
The protocol fits NeoShell's project workflow directly: the Host Profile chooses neosh transport, the Project can still choose tmux, zellij, or None, and the app can recover the transport session before deciding whether a new shell is required.
- SSH remains the bootstrap and trust path.
- QUIC carries control plus stdin/stdout streams after bootstrap.
- Session timeout defines how long a detached session remains available.
- Same-client reconnect can reclaim a stale attached session when the negotiated protocol supports it.
Server and network requirements
Neither option is a zero-configuration replacement for SSH. Mosh requires mosh-server and its UDP port range to be reachable. neosh requires neoshd, successful SSH bootstrap, and a reachable QUIC endpoint.
UDP mappings can expire faster than TCP mappings, so a QUIC application must choose between keep-alives and application-level resume. RFC 9308 describes this tradeoff; neosh makes resume part of the terminal protocol rather than assuming one connection stays alive forever.
How to choose
The useful comparison is not which protocol wins every category. It is whether the failure happens in the TCP connection, the terminal session, or the host workspace.
- Use plain SSH for maximum compatibility when a fresh connection is acceptable.
- Add tmux or zellij when host-side processes, panes, and workspace state must survive any client disconnect.
- Choose a Mosh-capable terminal when roaming and responsive local echo on high-latency links are the primary goals.
- Choose neosh in NeoShell when explicit detach/resume and recovery of the same terminal session are the primary goals.
- Combine a persistent host workspace with the transport that best matches the network failure you actually experience.
FAQ
Does NeoShell support Mosh?
No. NeoShell currently supports standard SSH and neosh transports. This comparison explains the different protocol models; it does not announce Mosh support in NeoShell.
Does neosh replace SSH?
No. NeoShell uses SSH to authenticate, locate and start neoshd, and establish trust before the interactive session moves to neosh over QUIC.
Do Mosh or neosh remove the need for tmux or zellij?
Not necessarily. tmux and zellij preserve host-side workspace structure and processes. Mosh and neosh address transport or terminal-session continuity, so the layers can be combined.
Which is better on a high-latency connection?
Mosh is specifically designed for responsive typing with predictive local echo. Choose neosh when explicit detach and resume of the same NeoShell terminal session is more important than Mosh-style local prediction.