8 ms·

A native graphical shell for SSH

370 points by mrcslws 3mo ago

tammer 3mo ago
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.
rdevsrex 3mo ago
This looks pretty cool! I can already imagine use cases for admin portals or other tools that I'd prefer to run over ssh.
toenail 3mo ago
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.
- dboreham 3mo ago
  Sometimes the browser is the only "computing platform" you have available (e.g. on some mobile devices, hotel kiosks).
supertroop 3mo ago
Defeats the purpose of the shell. The shell is for CLI interaction.
- metalliqaz 3mo ago
  command line shell vs graphical shell. My first experience with a graphical shell was dosshell[1]. For a while we called the Windows 3.1 interface "the shell". I guess the terminology has changed since that time. [1] https://en.wikipedia.org/wiki/DOS_Shell https://en.wikipedia.org/wiki/DOS_Shell
- hnlmorg 3mo ago
  No. A shell is any user interface. Windows shell is explorer.exe and it used to be possible to change that via a config line in a system INI file. SSH protocol also isn’t just for CLI work. It supports file transport (eg SFTP), TCP/IP forwarding and even SOCKS HTTP proxying. You also used to be able to run GUI applications over SSH via X11.
  - supertroop 3mo ago
    You have a very loose definition of a shell that conflicts with about 40 years of history.
    - mrcslws 3mo ago
      I wondered if this would be controversial. It all depends where you grew up. > Cairo, like Chicago, had a new shell (Microsoft’s favorite word for the user interface for launching programs and managing files) and a new file system https://hardcoresoftware.learningbyshipping.com/p/020-innovation-versus-shipping-the https://hardcoresoftware.learningbyshipping.com/p/020-innova... When I worked at Microsoft 2010 - 2014, the word "shell" was still used in this way. I decided to say "graphical shell", to make it clearer.
    - hnlmorg 3mo ago
      Not really no. I’ve been using shells and authoring new ones for around 40 years across a variety of platforms. The term has always been pretty loosely defined because as technology evolved the term “shell” was borrowed. So like I said, a shell can refer to a graphical core just as much as a text-based one. You can get web shells too. The original intent was that a shell is a thin wrapper on top of the OS to expose the hosts capabilities. But that hasn’t been an apt description for most of those 40 years.
      - b40d-48b2-979e 3mo ago
        Appeal to authority.
        deleted 3mo ago
akshayKMR 3mo ago
This is cool. Though I don't see why someone would want to do more work/design for the custom GUI rendering for a custom/renderer (your viewer app) ?
arnefm 3mo ago
Heresy!
torm 3mo ago
I can’t make up my mind if I love it or hate it. On one hand this is like SSHapi on the other there’s no structure, no contract… i had similar doubts with Cockpit.
tom1337890 3mo ago
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.
myaccountonhn 3mo ago
I am not sure I'd use this over exposing websites with wireguard as those will automatically work across platforms. But it looks like you could create some really cool experiences with it, and I'm happy people are exploring this space.
purplehat_ 3mo ago
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?
- _def 3mo ago
  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"
  - KomoD 3mo ago
    Ever since I started using Caddy, doing that has been soooo easy. Download the binary, make a Caddyfile myservice.example.com { basic_auth { admin some_password_hash_here } reverse_proxy :3000 } And then just "./caddy start"
    - Natfan 3mo ago
      does this work with multiple caddy servers? ie can you bind multiple caddy servers to port 80/443?
      - tcoff91 3mo ago
flying_sheep 3mo ago
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
- ori_b 3mo ago
  So, uh... X11? VNC? RDP?
  - flying_sheep 3mo ago
    No no not something on top of the UI stack. They also need framebuffer support so they are big headache to setup on headless server. What I mean is that we can bring some web tech to terminal natively. We don't even need a separated shell. Security and bi-directional communication is built by default because of UNIX socket. But we still need to think how to handle stuff like cookie, local storage, external CSS / JS, ...
    - ori_b 3mo ago
      Web technologies are significantly larger and more complex than framebuffers, and they don't even let you start arbitrary programs like Chrome under them.
- jerf 3mo ago
  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.
CamperBob2 3mo ago
Edit: withdrawing this objection, had no idea that right-clicking allowed the speed to be adjusted.
- pelzatessa 3mo ago
  but its just standard <video> element, in firefox I can even right-click to change the speed to 2x. It's certainly better privacy-wise.
- mrcslws 3mo ago
  Sure, I just added YouTube mirror link to the post: https://youtu.be/e40PLLuZ5KI https://youtu.be/e40PLLuZ5KI (The one on the website is the standard browser video player, not custom.)
  - CamperBob2 3mo ago
    Thanks (and to pelzatessa as well), TIL about the right-click menu on these. That'll come in handy.
saltamimi 3mo ago
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.
- jon-wood 3mo ago
  At the risk of being considered a snob I don’t want someone who can’t deal with SSH or RDP configuring servers within my company. If you can’t work out how to SSH into the server you sure as hell aren’t going to work out how to safely expose network services on it.
  - saltamimi 3mo ago
    Within your company, sure. But there's some engineers (think medical) who know standards like DICOM and PACS imaging but aren't familiar at all with OS internals or systems administration.
    - skydhash 3mo ago
      If you’re not a sysadmin, there’s no reason to wrestle around with OS internals and system tools. We have moved away from mainframes and now everyone is root on one’s computer, but honestly anything in /etc, /sbin and /usr/sbin should be irrelevant for daily workflows.
  - tonyedgecombe 3mo ago
    I can ssh into a server yet would still prefer a GUI for a lot of work.
nativeit 3mo ago
I thought this looks interesting, but was a little confused with what appears to be MacOS-only support at https://outerloop.sh/ https://outerloop.sh/? I'm running Ubuntu 24.04, I kind of assumed from context that it'd be something I could spin up in a few minutes just to give it a go?
- nativeit 3mo ago
  Also worth noting, my decision to give it a go relied mostly on the fact that I couldn't quite work out what the product is. Having "Outer Shell" and "Outer Loop" described as distinct-but-connected entities is a little confusing, IMO, which do I need to install, on what, and in what order? Cool idea anyway, no shade here.
  - al_borland 3mo ago
    I have also been having trouble grasping the difference between Outer Loop and Outer Shell. I thought maybe one was the desktop browser app for macOS and the other was something running locally on the Pi to create the socket. However, after bouncing between the links for the two, I don't think that assumption was correct.
PunchyHamster 3mo ago
> Isn’t it weird that this doesn’t already exist? It does. MobaXterm have a bunch of it already, file manager on the side and ability to pass X11
trashb 3mo ago
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.
- mrcslws 3mo ago
  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/ https://outerloop.sh/unix-domain-sockets/)
  - wang_li 3mo ago
    JavaScript and wasm should not be able to open generalized networks sockets because no one wants an asshole to be able to buy an ad on a shitty ad network and send malicious code to people’s browsers which attacks all the internal devices on the user’s network simply because the user wanted to read a movie review.
- deleted 3mo ago
  [deleted]
dwb 3mo ago
Just had a quick look but I like the look so far. I’ve been thinking along similar lines for ages but never quite got around to making something. I very much support any effort to make remoting less dependent on the archaic character grid.
setheron 3mo ago
I'm confused -- does this compile it live when the server ships code? How do we resolve dependencies, toolset etc.. Is the idea to just pick an old enough platform toolchain you expect to be present?
- mrcslws 3mo ago
  In all cases, the code is pre-compiled. A user never waits for anything to compile. When Outer Loop installs Outer Shell, it downloads pre-compiled binaries to the server. For Linux these are compiled against a manylinux ABI. Ditto for when Outer Shell installs one of the bundled apps. When a backend serves a native "web" app over HTTP it sends already-compiled ARM (or x86) code to the client. Dependencies are less of a concern for the frontend binaries. For backends, I use a dependency-light approach, static-linking anything that's needed. Of course, people are welcome to do backends however they want, and just tell Outer Shell about the systemd/launchd units via the API. I used this no-dependency approach to keep everything lightweight and to keep install steps trivial, but admittedly it pushes me in certain directions (for example, using custom binary formats rather than sqlite).
tjohnell 3mo ago
I’m good with just tailscale and self-hosted web-apps. Seems the main selling point is either native UX or reduced barriers to entry security-wise. I like barriers to entry.
Panzerschrek 3mo ago
> every app is a small HTTP server This adds unnecessary overhead for communication. using web and web-like approaches on desktop system is a terrible idea.
abnercoimbre 3mo ago
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 https://terminal.click [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=Offline%20Replay https://terminal.click/posts/2026/06/tui-stability/#:~:text=...
fnordpiglet 3mo ago
I prefer hytelnet and MUDs but I don’t count, I’m just too old.
bobajeff 3mo ago
I don't really know what outerframe frame is. I tried to understand from the video and the blog but I'm still not sure what it is. Is it like a web browser but instead of DOM, HTML and JS you have Swift and SwiftUI running in a sandbox? If so how would that work on non Apple devices? Also how much will that sandbox protect you?
- runjake 3mo ago
  It's purportedly cross-platform. The documentation leaves a lot to be desired, but it is described more here: https://outerframe.org/ https://outerframe.org/ and https://outerloop.sh/native-apps/ https://outerloop.sh/native-apps/
  - mrcslws 3mo ago
    Also a blog post about it, with its own video: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view-but-native.html https://probablymarcus.com/blocks/2026/05/10/like-a-web-view... It's a fun heretical idea, moving away from a "cross-platform" web to a "multi-platform" web. It's a cross-platform protocol that hands off to platform-specific frontend code. I think it's a natural direction for the web, in a world where LLMs can translate to other platforms.
abtinf 3mo ago
I wrote an early version of the Cylance AV desktop client. The UI side was a web app that talked to its windows service backend using HTTP over windows pipes. This was surprisingly easy to do using WCF.
xuhu 3mo ago
Being able to initiate a shell app from a regular remote ssh CLI prompt (like "ApacheConfig myhost.com" or "Editor ~/myrepo") might improve integration with people's existing CLI workflows. It does need an agent that starts with every X or Wayland session and waits for requests from remote SSH sessions to start an app.
hatradiowigwam 3mo ago
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
- forgot_old_user 3mo ago
  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).
  - shakna 3mo ago
    That is exactly what X was designed to do. And part of why X is considered insecure today.
  - advael 3mo ago
    I mean, I do this all the time via sshfs. I don't think these tools or ideas are bad, they just mostly aren't new, the innovation is maybe a particular ux or a particular bundle of toys?
- Modified3019 3mo ago
  > "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.
  - XorNot 3mo ago
    I mean that's true but the number of UIs which simply don't add access to necessary features in the name of "simplicity" is enormous. The poster child of this is the Microsoft Office ribbon.
Tepix 3mo ago
It's a cool video and I like the idea in general. The author mentions that the code runs in a sandbox. I'm surprised that WASM hasn't come up. You want the code to be platform agnostic anyway (it should run whether you start Outshell on Linux, macOS or whatever on different CPU architectures).
- mrcslws 3mo ago
  Thanks :) I wrote a previous blog post that discussed WASM in the FAQ: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view-but-native.html https://probablymarcus.com/blocks/2026/05/10/like-a-web-view...
wolvoleo 3mo ago
So a bit like X-forwarding used to do? Cool.
calmbonsai 3mo ago
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.
- mrcslws 3mo ago
  I think it's okay as long as: - 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.) More here: https://outerloop.sh/security/ https://outerloop.sh/security/
  - wang_li 3mo ago
    There’s no such thing as a root socket. Stop using that phrase.
mad182 3mo ago
Cool, I hate it.
guhcampos 3mo ago
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.
- NooneAtAll3 3mo ago
  I never heard of cockpit either what is it?
  - skydhash 3mo ago
    https://cockpit-project.org/ https://cockpit-project.org/
- jng 3mo ago
  If I'm not mistaken cockpit is web UI and doesn't run native code, important differences.
  - mrcslws 3mo ago
    Thanks for pointing this out. I'm not hating on Cockpit, but Outer Loop (with Outer Shell) has solved a lot more of the stack. Cockpit accepts the constraints of living in existing browsers, so it requires exposing a port to the internet or using some SSH port forwarding tool. Whereas I built a dedicated browser to push capabilities so that users can get a "Just point me to a server" flow. This thread has been useful -- I think Cockpit will also work great in Outer Loop. And it will be easy to add it as an app in Outer Shell.
    - dharmatech 3mo ago
      Your project is really cool. And, when a project announcement upsets this many people, it's a sign you're on the right path, or at least an interesting one. ; - )
cloudfudge 3mo ago
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.
Asooka 3mo ago
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.
IshKebab 3mo ago
I'm actually way more interested in option 2 - the VNC-like experience. TUI apps are convenient over SSH because they're right there in your terminal. But they suck because they're restricted to shitty monospaced character grids. Why can't we have something more like VNC over SSH? Like, `top` and `micro` but with good graphics? I did try doing something like that with the Kitty graphics protocol and you can get kind of close..ish, but it's really restricted by having to send everything as PNGs. Anyway upvote for not being blinkered and thinking terminals are just for CLI stuff and must be forever.
whalesalad 3mo ago
this exists as https://xpipe.io/ https://xpipe.io/
smusamashah 3mo ago
Feedback: Home pages of each of Outer Loop, Outer Frame and Outer Shell contain basic intro of each instead of a link redirecting to them. By the time I click the link and on the new Outer X I have already what Outer X I came from and what it meant.
syngrog66 3mo ago
not sure what problem this solves. smells like setup for a security exploit. tho my most generous take is its CV-ware
v3ss0n 3mo ago
UI/UX is very bad why would we need it over Warp / Wave Terminal
pdntspa 3mo ago
So.... webmin
aziis98 3mo ago
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
severino32 3mo ago
[dead]
Reuben_Santoso 3mo ago
[dead]
achille 3mo ago
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.
huflungdung 3mo ago
[dead]
gslepak 3mo ago
This is really cool. I love it. What'd be really funny would be for someone to use this to implement an app that's a terminal. XD
- mrcslws 3mo ago
  Ha, I’ve thought the same thing.
_eht 3mo ago
[dead]
BobbyTables2 3mo ago
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…
utopiah 3mo ago
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
goranmoomin 3mo ago
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?
- v3ss0n 2mo ago
  I never liked TUIs. Proper GUI , even Electron based apps are far superior than TUI , it just need to be built properly. But bad GUI is a bad GUI. This have all the UI/UX smells.
- Valodim 3mo ago
paweladamczuk 3mo ago
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.
virajk_31 3mo ago
coool, its very basic idea and neatly built. TUI is allows all the customization however GUI good for quick & less complex tasks.
rcarmo 3mo ago
I like the idea, but without a cross-platform OSS browser it’s hard to consider adopting it (and I am primarily a Mac/iOS user…)
vim-guru 3mo ago
Looks good. I'll stick to Emacs and tramp though.
rebooot 3mo ago
wow i really dig this concept, worked on something similar recently, a ssh browser as transport layer on top of ladybird with id profiles based on ssh pubkeys https://github.com/ricardo-reboot/sshttpd https://github.com/ricardo-reboot/sshttpd. also i think the web should head in this direction and give browsers an alternate transport layer other than http for browsing.
teekert 3mo ago
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/ https://zellij.dev/
- jrapdx3 3mo ago
  Thanks for the hint! Didn't know about zellij, but indeed looks very interesting. Downloaded and will try it out.
xuhu 3mo ago
Since the half of the app that is running on my local X or Wayland can only display a GUI and doesn't need QtNetwork, QtWebkit, Gtk Webview etc, what lightweight UI toolkit other than html+js do you recommend ?
mattbaconz 3mo ago
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.
nirui 3mo ago
> 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?
Lerc 3mo ago
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 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 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/ 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
deleted 3mo ago
[deleted]
bryan_w 3mo ago
You would have loved XUL
naikrovek 3mo ago
again, this is something that Plan 9 made very easy and that other operating systems ignored. I'm honestly getting tired of typing that. Bell Labs thought ahead when they made Plan 9. It's definitely not perfect, but it's got a lot of nice features that we are still reinventing 30 years later.
Kaizzen 3mo ago
[dead]
nibbula 3mo ago
Is this really the future that people want? https://raw.githubusercontent.com/outergroup/outershell/refs/heads/main/outershelld/outershelld.c https://raw.githubusercontent.com/outergroup/outershell/refs... https://raw.githubusercontent.com/outergroup/Top/refs/heads/main/Backend/main.c 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.
ValdikSS 3mo ago
The interface design reminded me of yunohost a bit.

370 points by mrcslws 3mo ago

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.

rdevsrex 3mo ago

This looks pretty cool! I can already imagine use cases for admin portals or other tools that I'd prefer to run over ssh.

toenail 3mo ago

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.

dboreham 3mo ago
Sometimes the browser is the only "computing platform" you have available (e.g. on some mobile devices, hotel kiosks).

supertroop 3mo ago

Defeats the purpose of the shell. The shell is for CLI interaction.

metalliqaz 3mo ago
command line shell vs graphical shell. My first experience with a graphical shell was dosshell[1]. For a while we called the Windows 3.1 interface "the shell". I guess the terminology has changed since that time. [1] https://en.wikipedia.org/wiki/DOS_Shell https://en.wikipedia.org/wiki/DOS_Shell
hnlmorg 3mo ago
No. A shell is any user interface. Windows shell is explorer.exe and it used to be possible to change that via a config line in a system INI file. SSH protocol also isn’t just for CLI work. It supports file transport (eg SFTP), TCP/IP forwarding and even SOCKS HTTP proxying. You also used to be able to run GUI applications over SSH via X11.
- supertroop 3mo ago
  You have a very loose definition of a shell that conflicts with about 40 years of history.
  - mrcslws 3mo ago
    I wondered if this would be controversial. It all depends where you grew up. > Cairo, like Chicago, had a new shell (Microsoft’s favorite word for the user interface for launching programs and managing files) and a new file system https://hardcoresoftware.learningbyshipping.com/p/020-innovation-versus-shipping-the https://hardcoresoftware.learningbyshipping.com/p/020-innova... When I worked at Microsoft 2010 - 2014, the word "shell" was still used in this way. I decided to say "graphical shell", to make it clearer.
  - hnlmorg 3mo ago
    Not really no. I’ve been using shells and authoring new ones for around 40 years across a variety of platforms. The term has always been pretty loosely defined because as technology evolved the term “shell” was borrowed. So like I said, a shell can refer to a graphical core just as much as a text-based one. You can get web shells too. The original intent was that a shell is a thin wrapper on top of the OS to expose the hosts capabilities. But that hasn’t been an apt description for most of those 40 years.
    - b40d-48b2-979e 3mo ago
      Appeal to authority.
      - deleted 3mo ago

akshayKMR 3mo ago

This is cool. Though I don't see why someone would want to do more work/design for the custom GUI rendering for a custom/renderer (your viewer app) ?

arnefm 3mo ago

Heresy!

torm 3mo ago

I can’t make up my mind if I love it or hate it. On one hand this is like SSHapi on the other there’s no structure, no contract… i had similar doubts with Cockpit.

tom1337890 3mo ago

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.

myaccountonhn 3mo ago

I am not sure I'd use this over exposing websites with wireguard as those will automatically work across platforms. But it looks like you could create some really cool experiences with it, and I'm happy people are exploring this space.

purplehat_ 3mo ago

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?

_def 3mo ago
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"
- KomoD 3mo ago
  Ever since I started using Caddy, doing that has been soooo easy. Download the binary, make a Caddyfile myservice.example.com { basic_auth { admin some_password_hash_here } reverse_proxy :3000 } And then just "./caddy start"
  - Natfan 3mo ago
    does this work with multiple caddy servers? ie can you bind multiple caddy servers to port 80/443?
    - tcoff91 3mo ago

flying_sheep 3mo ago

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

ori_b 3mo ago
So, uh... X11? VNC? RDP?
- flying_sheep 3mo ago
  No no not something on top of the UI stack. They also need framebuffer support so they are big headache to setup on headless server. What I mean is that we can bring some web tech to terminal natively. We don't even need a separated shell. Security and bi-directional communication is built by default because of UNIX socket. But we still need to think how to handle stuff like cookie, local storage, external CSS / JS, ...
  - ori_b 3mo ago
    Web technologies are significantly larger and more complex than framebuffers, and they don't even let you start arbitrary programs like Chrome under them.
jerf 3mo ago
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.

CamperBob2 3mo ago

Edit: withdrawing this objection, had no idea that right-clicking allowed the speed to be adjusted.

pelzatessa 3mo ago
but its just standard <video> element, in firefox I can even right-click to change the speed to 2x. It's certainly better privacy-wise.
mrcslws 3mo ago
Sure, I just added YouTube mirror link to the post: https://youtu.be/e40PLLuZ5KI https://youtu.be/e40PLLuZ5KI (The one on the website is the standard browser video player, not custom.)
- CamperBob2 3mo ago
  Thanks (and to pelzatessa as well), TIL about the right-click menu on these. That'll come in handy.

saltamimi 3mo ago

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.

jon-wood 3mo ago
At the risk of being considered a snob I don’t want someone who can’t deal with SSH or RDP configuring servers within my company. If you can’t work out how to SSH into the server you sure as hell aren’t going to work out how to safely expose network services on it.
- saltamimi 3mo ago
  Within your company, sure. But there's some engineers (think medical) who know standards like DICOM and PACS imaging but aren't familiar at all with OS internals or systems administration.
  - skydhash 3mo ago
    If you’re not a sysadmin, there’s no reason to wrestle around with OS internals and system tools. We have moved away from mainframes and now everyone is root on one’s computer, but honestly anything in /etc, /sbin and /usr/sbin should be irrelevant for daily workflows.
- tonyedgecombe 3mo ago
  I can ssh into a server yet would still prefer a GUI for a lot of work.

nativeit 3mo ago

I thought this looks interesting, but was a little confused with what appears to be MacOS-only support at https://outerloop.sh/ https://outerloop.sh/? I'm running Ubuntu 24.04, I kind of assumed from context that it'd be something I could spin up in a few minutes just to give it a go?

nativeit 3mo ago
Also worth noting, my decision to give it a go relied mostly on the fact that I couldn't quite work out what the product is. Having "Outer Shell" and "Outer Loop" described as distinct-but-connected entities is a little confusing, IMO, which do I need to install, on what, and in what order? Cool idea anyway, no shade here.
- al_borland 3mo ago
  I have also been having trouble grasping the difference between Outer Loop and Outer Shell. I thought maybe one was the desktop browser app for macOS and the other was something running locally on the Pi to create the socket. However, after bouncing between the links for the two, I don't think that assumption was correct.

PunchyHamster 3mo ago

> Isn’t it weird that this doesn’t already exist? It does. MobaXterm have a bunch of it already, file manager on the side and ability to pass X11

trashb 3mo ago

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.

mrcslws 3mo ago
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/ https://outerloop.sh/unix-domain-sockets/)
- wang_li 3mo ago
  JavaScript and wasm should not be able to open generalized networks sockets because no one wants an asshole to be able to buy an ad on a shitty ad network and send malicious code to people’s browsers which attacks all the internal devices on the user’s network simply because the user wanted to read a movie review.
deleted 3mo ago
[deleted]

dwb 3mo ago

Just had a quick look but I like the look so far. I’ve been thinking along similar lines for ages but never quite got around to making something. I very much support any effort to make remoting less dependent on the archaic character grid.

setheron 3mo ago

I'm confused -- does this compile it live when the server ships code? How do we resolve dependencies, toolset etc.. Is the idea to just pick an old enough platform toolchain you expect to be present?

mrcslws 3mo ago
In all cases, the code is pre-compiled. A user never waits for anything to compile. When Outer Loop installs Outer Shell, it downloads pre-compiled binaries to the server. For Linux these are compiled against a manylinux ABI. Ditto for when Outer Shell installs one of the bundled apps. When a backend serves a native "web" app over HTTP it sends already-compiled ARM (or x86) code to the client. Dependencies are less of a concern for the frontend binaries. For backends, I use a dependency-light approach, static-linking anything that's needed. Of course, people are welcome to do backends however they want, and just tell Outer Shell about the systemd/launchd units via the API. I used this no-dependency approach to keep everything lightweight and to keep install steps trivial, but admittedly it pushes me in certain directions (for example, using custom binary formats rather than sqlite).

tjohnell 3mo ago

I’m good with just tailscale and self-hosted web-apps. Seems the main selling point is either native UX or reduced barriers to entry security-wise. I like barriers to entry.

Panzerschrek 3mo ago

> every app is a small HTTP server This adds unnecessary overhead for communication. using web and web-like approaches on desktop system is a terrible idea.

abnercoimbre 3mo ago

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 https://terminal.click [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=Offline%20Replay https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

fnordpiglet 3mo ago

I prefer hytelnet and MUDs but I don’t count, I’m just too old.

bobajeff 3mo ago

I don't really know what outerframe frame is. I tried to understand from the video and the blog but I'm still not sure what it is. Is it like a web browser but instead of DOM, HTML and JS you have Swift and SwiftUI running in a sandbox? If so how would that work on non Apple devices? Also how much will that sandbox protect you?

runjake 3mo ago
It's purportedly cross-platform. The documentation leaves a lot to be desired, but it is described more here: https://outerframe.org/ https://outerframe.org/ and https://outerloop.sh/native-apps/ https://outerloop.sh/native-apps/
- mrcslws 3mo ago
  Also a blog post about it, with its own video: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view-but-native.html https://probablymarcus.com/blocks/2026/05/10/like-a-web-view... It's a fun heretical idea, moving away from a "cross-platform" web to a "multi-platform" web. It's a cross-platform protocol that hands off to platform-specific frontend code. I think it's a natural direction for the web, in a world where LLMs can translate to other platforms.

abtinf 3mo ago

I wrote an early version of the Cylance AV desktop client. The UI side was a web app that talked to its windows service backend using HTTP over windows pipes. This was surprisingly easy to do using WCF.

xuhu 3mo ago

Being able to initiate a shell app from a regular remote ssh CLI prompt (like "ApacheConfig myhost.com" or "Editor ~/myrepo") might improve integration with people's existing CLI workflows. It does need an agent that starts with every X or Wayland session and waits for requests from remote SSH sessions to start an app.

hatradiowigwam 3mo ago

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

forgot_old_user 3mo ago
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).
- shakna 3mo ago
  That is exactly what X was designed to do. And part of why X is considered insecure today.
- advael 3mo ago
  I mean, I do this all the time via sshfs. I don't think these tools or ideas are bad, they just mostly aren't new, the innovation is maybe a particular ux or a particular bundle of toys?
Modified3019 3mo ago
> "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.
- XorNot 3mo ago
  I mean that's true but the number of UIs which simply don't add access to necessary features in the name of "simplicity" is enormous. The poster child of this is the Microsoft Office ribbon.

Tepix 3mo ago

It's a cool video and I like the idea in general. The author mentions that the code runs in a sandbox. I'm surprised that WASM hasn't come up. You want the code to be platform agnostic anyway (it should run whether you start Outshell on Linux, macOS or whatever on different CPU architectures).

mrcslws 3mo ago
Thanks :) I wrote a previous blog post that discussed WASM in the FAQ: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view-but-native.html https://probablymarcus.com/blocks/2026/05/10/like-a-web-view...

wolvoleo 3mo ago

So a bit like X-forwarding used to do? Cool.

calmbonsai 3mo ago

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.

mrcslws 3mo ago
I think it's okay as long as: - 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.) More here: https://outerloop.sh/security/ https://outerloop.sh/security/
- wang_li 3mo ago
  There’s no such thing as a root socket. Stop using that phrase.

mad182 3mo ago

Cool, I hate it.

guhcampos 3mo ago

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.

NooneAtAll3 3mo ago
I never heard of cockpit either what is it?
- skydhash 3mo ago
  https://cockpit-project.org/ https://cockpit-project.org/
jng 3mo ago
If I'm not mistaken cockpit is web UI and doesn't run native code, important differences.
- mrcslws 3mo ago
  Thanks for pointing this out. I'm not hating on Cockpit, but Outer Loop (with Outer Shell) has solved a lot more of the stack. Cockpit accepts the constraints of living in existing browsers, so it requires exposing a port to the internet or using some SSH port forwarding tool. Whereas I built a dedicated browser to push capabilities so that users can get a "Just point me to a server" flow. This thread has been useful -- I think Cockpit will also work great in Outer Loop. And it will be easy to add it as an app in Outer Shell.
  - dharmatech 3mo ago
    Your project is really cool. And, when a project announcement upsets this many people, it's a sign you're on the right path, or at least an interesting one. ; - )

cloudfudge 3mo ago

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.

Asooka 3mo ago

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.

IshKebab 3mo ago

I'm actually way more interested in option 2 - the VNC-like experience. TUI apps are convenient over SSH because they're right there in your terminal. But they suck because they're restricted to shitty monospaced character grids. Why can't we have something more like VNC over SSH? Like, `top` and `micro` but with good graphics? I did try doing something like that with the Kitty graphics protocol and you can get kind of close..ish, but it's really restricted by having to send everything as PNGs. Anyway upvote for not being blinkered and thinking terminals are just for CLI stuff and must be forever.

whalesalad 3mo ago

this exists as https://xpipe.io/ https://xpipe.io/

smusamashah 3mo ago

Feedback: Home pages of each of Outer Loop, Outer Frame and Outer Shell contain basic intro of each instead of a link redirecting to them. By the time I click the link and on the new Outer X I have already what Outer X I came from and what it meant.

syngrog66 3mo ago

not sure what problem this solves. smells like setup for a security exploit. tho my most generous take is its CV-ware

v3ss0n 3mo ago

UI/UX is very bad why would we need it over Warp / Wave Terminal

pdntspa 3mo ago

So.... webmin

aziis98 3mo ago

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

severino32 3mo ago

[dead]

Reuben_Santoso 3mo ago

[dead]

achille 3mo ago

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.

huflungdung 3mo ago

[dead]

gslepak 3mo ago

This is really cool. I love it. What'd be really funny would be for someone to use this to implement an app that's a terminal. XD

mrcslws 3mo ago
Ha, I’ve thought the same thing.

_eht 3mo ago

[dead]

BobbyTables2 3mo ago

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…

utopiah 3mo ago

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

goranmoomin 3mo ago

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?

v3ss0n 2mo ago
I never liked TUIs. Proper GUI , even Electron based apps are far superior than TUI , it just need to be built properly. But bad GUI is a bad GUI. This have all the UI/UX smells.
Valodim 3mo ago

paweladamczuk 3mo ago

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.

virajk_31 3mo ago

coool, its very basic idea and neatly built. TUI is allows all the customization however GUI good for quick & less complex tasks.

rcarmo 3mo ago

I like the idea, but without a cross-platform OSS browser it’s hard to consider adopting it (and I am primarily a Mac/iOS user…)

vim-guru 3mo ago

Looks good. I'll stick to Emacs and tramp though.

rebooot 3mo ago

wow i really dig this concept, worked on something similar recently, a ssh browser as transport layer on top of ladybird with id profiles based on ssh pubkeys https://github.com/ricardo-reboot/sshttpd https://github.com/ricardo-reboot/sshttpd. also i think the web should head in this direction and give browsers an alternate transport layer other than http for browsing.

teekert 3mo ago

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/ https://zellij.dev/

jrapdx3 3mo ago
Thanks for the hint! Didn't know about zellij, but indeed looks very interesting. Downloaded and will try it out.

xuhu 3mo ago

Since the half of the app that is running on my local X or Wayland can only display a GUI and doesn't need QtNetwork, QtWebkit, Gtk Webview etc, what lightweight UI toolkit other than html+js do you recommend ?

mattbaconz 3mo ago

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.

nirui 3mo ago

> 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?

Lerc 3mo ago

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 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 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/ 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

deleted 3mo ago

[deleted]

bryan_w 3mo ago

You would have loved XUL

naikrovek 3mo ago

again, this is something that Plan 9 made very easy and that other operating systems ignored. I'm honestly getting tired of typing that. Bell Labs thought ahead when they made Plan 9. It's definitely not perfect, but it's got a lot of nice features that we are still reinventing 30 years later.

Kaizzen 3mo ago

[dead]

nibbula 3mo ago

Is this really the future that people want? https://raw.githubusercontent.com/outergroup/outershell/refs/heads/main/outershelld/outershelld.c https://raw.githubusercontent.com/outergroup/outershell/refs... https://raw.githubusercontent.com/outergroup/Top/refs/heads/main/Backend/main.c 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.

ValdikSS 3mo ago

The interface design reminded me of yunohost a bit.