A native graphical shell for SSH

Original Article ↗ Hacker News Discussion ↗

Concept & Terminology

  • The project is a “native graphical shell for SSH” built around Outer Loop (client), Outer Shell (remote apps), and Outer Frame (native frontend protocol).
  • Debate over the word “shell”: some insist it historically implies CLI; others argue it’s long been used for graphical desktops (e.g., DOS Shell, GNOME Shell, Finder) and any UI “thin layer” around the OS.
  • Several commenters are confused about how Outer Loop vs. Outer Shell vs. Outer Frame fit together and which to install where.

Use Cases & Appeal

  • Fans see value for:
    • Remote experiment/ML/dev servers (Jupyter, TensorBoard, robotics).
    • Treating a remote box as a “second computer” with GUI tools over SSH.
    • Lowering the barrier for people uncomfortable with pure SSH/TUI.
  • Some like the idea of graphical file browsing and admin tasks over SSH, plus the “just point me to a server” UX without manual port forwarding or reverse proxies.

Comparisons & Prior Art

  • Frequently compared to:
    • X11/Wayland forwarding, VNC, RDP, xpra, webmin, Cockpit, MobaXterm, WebSSH, sshfs, tailscale + web apps, and other “SSH + GUI” setups.
    • Electron-style frontend/backend splits and web UIs over HTTP.
  • Some argue this mostly repackages SSH port forwarding and HTTP servers with nicer UX; others say the novelty is the dedicated SSH-aware “browser” and native-app protocol.

Security & Architecture Concerns

  • Browsers intentionally lack raw socket/Unix-socket access due to security; project’s dedicated client sidesteps this with an allow-list and “sudo awareness.”
  • Critics worry about new attack surface, native code delivery, and parallels to abandoned tech like ActiveX.
  • Some highlight that replacing HTTPS with SSH doesn’t inherently avoid the “exposed port” and install/agent issues.

UX, Performance & Platform Issues

  • Mixed sentiment: some love escaping “1960s character grids”; others defend TUIs as efficient and sufficient.
  • X11 forwarding is criticized as too slow or clunky in real use; proponents think better protocols or delta-based rendering could help.
  • Complaints about macOS-only client availability and lack of clear, concise documentation.
  • Skeptics say existing tools (Cockpit, sshfs, wireguard, Caddy, VNC/RDP) already solve most problems; others view this as a fresh, promising experiment in remote-first GUIs.