Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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
by utopiah - 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.
by teekert - Thanks for the hint! Didn't know about zellij, but indeed looks very interesting. Downloaded and will try it out.by jrapdx3
- 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.by tammer
- 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 terminalby flying_sheep
- So, uh... X11? VNC? RDP?by ori_b
- If your UI is not fully controllable with a keyboard, the same forces that made that happen will eventually make a mouse mandatory for this hypothetical tech stack too.
The terminal has no Platonic quality of being keyboard only. It is an accident of history and the limitations it has had. Remove the limitations and remove the accident of history and you will just end up drawn into the strange attractor of GUIs, warts and all.
There could be a brief honeymoon where the tech stack looks like some of you are imagining in your heads, but it would only last as long as it wasn't used by very many people. Google "gemini protocol" for a similar situation. That protocol has basically a cap on how popular it could possibly get before it just turned into HTTP B as the rest of the world forcibly upgraded it regardless of what the core project thinks. They exist in the shadow of HTTP, as the terminal exists in the shadow of GUIs. This is not a bad thing. It is what lets them be what they are. The shadows of GUIs or HTTP is large and there is plenty of space to be. Trying to give the terminal more GUI capabilities is like trying to give Gemini more web capabilities; you'll just end up in the same place, only with less refinement.
by jerf - 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.
by achille - 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.
by calmbonsai - I think it's okay as long as:
More here: https://outerloop.sh/security/- 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.)by mrcslws - 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.)
[1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...
by abnercoimbre - 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.
by guhcampos - I never heard of cockpit either
what is it?
by NooneAtAll3 - If I'm not mistaken cockpit is web UI and doesn't run native code, important differences.by jng
- > Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Sincerely, HN Guidelines Police :-)
by gurjeet - 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?
by purplehat_ - My typical use case for SSH port forwarding is to rescue a network from some kind of configuration failure.by protocolture
- HTTP basic auth is not secure.by shakna
- 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)
by procaryote - 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"by _def
- 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.
by mrcslws - 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"
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.For browsers, capabilities like connecting to Unix sockets have been dismissed as extremely nicheby trashb - Quick response regarding security:
On various Mozilla forums that I saw, the discussion was basically: 1. We can't just allow the browser to connect to any socket, since many either explicitly don't want browsers connecting to them, or are oblivious to browsers. 2. ...so we need to also add some sort of allow list 3. ...this is getting too complicated for such a niche feature.
So I think the nicheness was the high-order bit here.
(FYI, Outer Loop does add an allow-list: https://outerloop.sh/unix-domain-sockets/)
by mrcslws - 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 think this is a `There’s no such thing as bad publicity`by aslihana
- >"Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer
I need something like this for network management tools.
by protocolture - 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" ;)by tway235
- This resembles Plan9 more than UNIX. I wouldn't put UNIX up on a pedestal.by hedgehog
- > "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.
by Modified3019 - 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).