It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all.

Two arguments:

- TUIs are not inherently superior to GUIs

- SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well

In fact, these two arguments were already realized by UNIX 30 years ago, and we already have one solution: the X protocol and ssh -X.

Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer. (If you believe that this works, try it out yourself. It is an abysmal experience.)

However the above needs still needed to be satisfied by so much people, and apps that needed it started to be developed as web servers, stuff like jupyter notebooks. It turns out that the web’s document format coupled with a styling solution and a client-side scripting language, with all of its warts and drawbacks, became a viable solution as a display layer for interactive apps. In fact, since it started from remote documents, network transparency is built-in.

It would be dumb to not realize that the HTML/CSS/JS stack did win a dominant position for desktop apps, with all of the Electron apps, and utilize the web as a display layer for the above. I see the project in a similar vein, i.e. utilizing HTML/CSS/JS to provide a display layer for remote apps via SSH.

Also note that Electron apps has the same split with X, where the display server and the client are separated: it's called the "renderer process" and the "main process", and the two processes talk via IPC (where the display server would be the renderer process running embedded Chromium, the display client would be the Electron main process, and the stuff that the client sends to the server would be the contents of the renderer JS bundle). I think, theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport. I think this would be not far from the above idea?

This appears to me like a solution in search of a problem, like many others before it...the quote below seems relevant to this effort.

"Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer

I like the idea of separating the frontend and backend of a graphical app. But I feel like this is hardly a novel idea, maybe I'm missing something.

I take it you don't know about "X11Forwarding yes" or "html5 web app"

  For browsers, capabilities like connecting to Unix sockets have been dismissed as extremely niche

That is a security concern, that's why it isn't implemented. At least raw unix socks. You can have WebSockets and other ports only limited to http.

i'm trying to understand how outer shell works here. on the website you give the following as your motivation:

> Apps like Jupyter and Tensorboard are not typically visible to standard web browsers if they’re running on remote servers, because it would be terribly unsafe to let the whole internet touch this app. Instead, they run on a local port on the server, which your computer can’t access directly.

> Classically, to get access to these, you had to open a new terminal and run:

> ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &

> ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &

is this true? isn't the normal thing just to do this ssh forwarding for prototyping, then for deployment, you set up a website like myjupyternotebook.com, and then set up auth so that others can't access it. HTTP basic auth is not too much work.

if you want SSH, not HTTP, to be what's publicly exposed, there's other options too, like putting it behind a VPN or tunnel.

all this to say, outer loop is super cool, but I don't get it. I must be missing something about why you built it, so could you help me understand?

Author apparently has never heard about Cockpit.

Everything they mention as "missing", or "novel" has been part of Cockpit for over a decade, from socket-based web server connection, backend-frontend separation for server apps and the whole idea of a server console with shell access itself.

To answer them: "Isn’t it weird that this doesn’t already exist?" - No, it's not, because it has existed for ages.

Lovely writeup! I'll bookmark this for my own research.

My terminal's "clickity clackity" features [0] are local to the machine so I lose graphical-ness as soon as we remote in somewhere.

That's starting to change a bit with offline replay [1] where the native GUI and TUI work in tandem to unlock some rewind. But there's quite a road ahead and I love seeing others experiment properly. (Terminals are massively underserved.)

[0] https://terminal.click

[1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

Do not do this. There are many, many excellent long-standing security and "web control plane isolation" reasons browsers are not permitted generic socket permissions.

The closest mechanical analog that comes to mind is why 3-wheeled ATVs are a bad idea.

  - sockets are blocked by default, until they are added to an allow-list explicitly on the server side
  - True sudo awareness ensures root sockets aren't reachable without the sudo password. (This capability is important, because otherwise you create an incentive for people to run root backends with user-accessible sockets.)

This is amazing! Most definitely headed in the right direction. The separation layer between front and back must be cut at the smallest possible 'slice'.

Lots of people here snarking would understand if they 'felt' the latency and additional overhead. Not enough thought has been put in carfully slicing the data for individual use cases.

I'd go even further, in his demo of 'generating load by moving the config often' -- I think that 'top' app should have 'jit-ed' more of the rendering on the client such that the only information traversing pi<>client is compresed delta's of the ps hose.

That's interesting idea. If we put into CLI with some ANSI escape code, that may become something real. Imagine a normal terminal app just render part of the UI in web and communicating in UNIX socket. While doing the fancy UI, everything is still controllable with keyboard, and optionally with mouse. The UI will fallback to text UI for older terminal

I think the approach here where interfacing with a device is considered from first principles is one that is rarely taken on, and this is a thought provoking implementation. Kudos.

Not what OP means but there is Zellij [0]

Zellij is nice, it's as close to a window manager in a terminal as I ever got. Right now I'm trying to get used to it in Termius, with a Logitech Pebble for some light remote devving.

[0] https://zellij.dev/

Ok few resources people interested in the topic might like on the "Web can do so much more front" :

- WebDAV to serve files, very quick to setup using e.g. CopyParty. It's important this way your Web applications can then pass content to each other.

- WebSSH to get a terminal via the Web and thus potentially backend maintenance, e.g. start/stop CopyParty (also useful to bypass corporate firewalls and connect to your machine)

- WebTop container based on Selkies to get a full containerized environment, including a graphical interface. You can run pretty much any of your native application in there, even video games. Can be local or remote at 60fps.

- WebContainers to run containers directly from the browser

- QEMU-wasm to run a different architecture on yours, again from the browser

Terminal people forget how hostile SSH is to anyone who didn't learn it in college.

If this lowers the floor for small teams managing a VPS without hiring a platform person, that's a win. I'm just curious how it handles keys and jump hosts.

This reminds me of an idea that I build a PoC of many years ago (maybe 2013 if I recall) that I always felt was the nugget of a useful idea. You would SSH into a server and processes on the other end would emit data which was then displayed in a webapp that was served from a localhost port, with a local backend that consumed the data. So for example a short-lived web-based remote 'top'. I did it as part of a company-internal hackathon and thought it was really cool, but nobody else was impressed with it. It was a very half-baked idea, and this looks like a fully-baked version of it. I'll check it out.

Love it!

I also did some experiments some time ago. The thing this is missing for me is the ability to also run arbitrary commands other that just using a few premade apps. In fact I think this stuff becomes really interesting when you put a real "shell" on top of this.

And I don't mean a classical posix shell, something that can be used to leverage the full power of the custom ui and frontend. Also a must have is "nestable connections".

The experiment I was doing was with a web interface and a statically compiled Go backend (for easy deployment via ssh). Maybe some day I will finish it xD

That's similar to the direction I went with my PC. It's a server that sits in a datacenter. It is wireguard protected and has SSH access for general stuff, copyparty for file access, webtop in a container for graphical tasks like audio editing, software like Navidrome for music and Immich for photos.

I could just call it a "home" lab server. But I actually use it as a general purpose computer, not just a server.

Interesting, kind of like a more fancy web shell. Haven't really ever seen the need for those, mostly because terminals work better than browsers.

In general I would like to see a web browser escape sequence for console applications. Just send a command to the terminal to connect a web browser to your stdin/out and present any UI you want over html. The terminal can then open a regular socket listening on localhost and act as a CGI server. For security the terminal should pick a random IP in the localhost range and a random URL. Technically that is security by obscurity, but guessing a cryptographically secure URL should be hard enough for attackers. The reasons to do it as an escape sequence and not just have the application open a socket and start the browser are: To enable remote GUI; To avoid the complexity of each application implementing networking; To enable better desktop integration, since the terminal itself is part of the Desktop Environment, so it can start a DE-specific browser, preferably in single-application mode. Also, it should be possible to automatically put the application in the background so you basically just run GUI applications like normal.

Is this really the future that people want?

https://raw.githubusercontent.com/outergroup/outershell/refs...

https://raw.githubusercontent.com/outergroup/Top/refs/heads/...

I am surprised at the lack of technical criticism. In the past, even an ignorance of history could be useful, since one would have to solve again the problems in detail, and so be forced to acquire a deep understanding of the issues. Now one can sell this paper clock with chaotic internal workings that thwarts human fabrication or maintenance.

I think this is broadly similar to a thing I built as a Proof of Concept a while ( eek youtube video is 11 years old, time does fly) ago. It had a server that only listened on localhost and required a reverse proxy to make it available via https. Numerous one line commands could do that job.

https://www.youtube.com/watch?v=7namj7iy16Y&t=60s

Going to a native, but still browser-ish, client might simplify it somewhat as a ssh rather than https program, electron didn't exist when I started on this thing though.

If you go to the simple tick demo around 7 minutes in https://youtu.be/7namj7iy16Y?t=433 It shows a minimal node app running and connecting to the socket indicated by process.env.WEBSESSION to open a window on the client and sends it the webpage to handle it's own output.

I have been recently revisiting some of the ideas here using web technologies that have been created since (using promises, web-components for the window). At the moment I'm doing the whole thing client side, which actually makes it a completely different beast. I think both browser hosted backend, or real machine hosted backend have merit, but somewhat incompatible. I'm still pondering how to reconcile this.

The entirely browser side means you can host a command line environment on neocities https://lerc.neocities.org/ (has a bug where you need to reload the page once to get it working, but then it's good) It is also very much just proof-of-concept.

If you try the client thing out on neocities. Some command suggestions that reveal some of the subtleties.

    foo
    bar
    ls -al /bin
    view /res/image/slice8.webp
    cat terminal.html |hd

> These HTTP servers will typically be private, inaccessible to other devices on the network. Instead, you’ll use them over SSH, or locally.

So, if I read it correctly, SSH is there to provide connectivity and security, and the core app idea is based on HTTP and web?

On the HTTP side, there are already some "app managers" such as Dokku and Coolify, and you can already `ssh ...-L...` map their ports to your local. But I guess the browser you build will do that (or something similar) automatically to make it more convenient for the user, so that's nice.

Not sure about the Outerframe idea tho. Right now you can already build things with webasm and have it send commands to draw stuff on to a canvas to create very rich custom UI elements, that is in addition to the standard HTML UI elements provided by the browser. Why another standard?

One of the more interesting pieces of Microsoft software is the Windows Admin Center where it's a web app to configure a Windows Server. Ideally, it was made for core installs where there's no GUI but it's there as a viable web management panel.

The tool from OP and WAC are pretty similar in terms of functionality and usecase. Why would you want this? Well, imagine your team needing to be able to do server functions but you have less technical team members to do it for you, which is very often the case in big places, most people are familiar with the web browser and having a website to do these sorts of actions makes it easier to have things done in one place without a lot of tools like Remote Desktop, SSH, WinRM, etc. configured.

Lovely video and ingenious implementation. Kudos!

As someone managing various servers, both at home and at work, I see how this can be really useful. I see it not in the production space yet but rather in the experimenting, using a Linux machine as a second compute device!

So regarding your last point, I'm convinced. I think it is useful! The one fact that is bugging me is that now it requires a client specific app, with GUI, on my PC and I wonder if using ssh port forwarding could reduce the surface. I mean I wonder if either having a rich client that executes commands via ssh or a rich server (including Web Server) with ssh port wouldn't suffice, so that I can avoid installing stuff on the server AND on my computer.

Reminds me of “WebRSH” back in the day.

There was also a standalone Java based SSH client that worked from browsers. (Of course now with WebSockets and modern JavaScript capabilities, no need to have the a “real” SSH client on the user’s actual system…)

Unfortunately, not sure there is enough drive for mainstream applications to be developed in for this proposed “web native” interface. Practically speaking, there would probably have to be a way to run them as native GUI apps without the browser or for a text terminal.

Unfortunately, the three environments have relatively little in common aside from the trivial parts… Operating efficiently in all quickly becomes nontrivial…

I hired a programmer and after giving him his Linux laptop let him set up a few things. A couple hours later he asked me where he could get PuTTY for it, and I recognized a huge gap in my interview coverage.

No. It’s just that now more people are using Linux the more the ux decisions that were made 40 years ago will be questioned.

Almost all dev facing machines have ssh server installed and accessible.

Why ssh terminal has to look like character-only trash from 1960s? Why a TUI is the best thing we pipe through ssh? Why I cannot watch a 4k movie in the terminal or browse the web using pinch to zoom ?

that seems a little harsh. I think there is a real usability gap which this takes a crack at.

Some ideas like using viewing a linux dir over _ssh_ using native UI components.. seem cool.

I do agree, some of these do seem like they have already been solved in other ways (like an sshfs mount).

> "Those who do not understand Unix

Funny enough, that right there is the actual fundamental problem here.

I am reminded of a post or blog long ago that talked about programmable thermostats and how awful they are for most people to use despite how powerfully in the weeds one can get with them. Basically summarizing the issue as something like “People do not want to learn your arcane system, they just want the benefit it’s advertising”. A good UI knows how to minimize that gap.

This resembles Plan9 more than UNIX. I wouldn't put UNIX up on a pedestal.

this kind of dismissive comments is why many apps have an awful usability. If someone thinks a web interface would be easier than a text terminal, there's at least one customer in need for a product (which either doesn't exist or they could not "googlify") - it's also why I welcome AI generating apps on the fly, "replacing" engineers who "know better" ;)

>"Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer

I need something like this for network management tools.

I think this is a `There’s no such thing as bad publicity`

It's like they decided to reinvent webmin

UNIX/GNU/LINUX is not TUI. Period.

That quote does not have anything against GUIs, does it?

Or did you mean it in another way?

I think there are different clusters of people who use servers, SSH, etc.

I'm closer to the cluster that uses them for deep learning experiments, GPU kernel optimization, robot development (a robot is just a server that moves!)... use cases where you are explicitly using a remote computer.

For this cluster of people, I think this tool feels more intuitive than the flow you suggest. But maybe I'm projecting!

And, to me, this just feels like one of the fundamental things that could exist; it's like a graphical operating system, but remote-first.

I guess it saves you the hassle of dealing with reverse proxies and TLS certs if your use case is "userbase is 1 person and it is me, and i only access services from a desktop os"

  myservice.example.com {
   basic_auth {
    admin some_password_hash_here
   }
   reverse_proxy :3000
  }

Btw, if you find yourself sending a lot of ports over ssh, you can also consider the option of having ssh start a socks5 proxy

ssh -D 4711 -q -C -N user@host

sets localhost:4711 up as a socks5 proxy you can tell your browser to use

...

A wireguard VPN is better of course; among other things because ssh is multiplexing over a single TCP connection and will encounter head of line blocking (where one dropped packet blocks all forwarded traffic until resent)

HTTP basic auth is not secure.

My typical use case for SSH port forwarding is to rescue a network from some kind of configuration failure.