With the web browser, we have really figured out a good flow for how one device (the “server”) can provide an experience on another device (the “client”).
This raises a fun idea: imagine if servers and edge devices could serve up a browser-based graphical “shell” so they can be used from other devices. The shell would provide a home screen of apps. In this shell, every app is a small HTTP server, serving up a web user interface. The shell would provide an API so that apps can look up each other’s URLs. For example, apps could register themselves as a text editor, so you can double-click text files in one app to open them in the editor app. These graphical apps would be an alternative to terminal-based apps.
These HTTP servers will typically be private, inaccessible to other devices on the network. Instead, you’ll use them over SSH, or locally. Unlike most existing web-based server tools, these HTTP servers won’t typically use localhost ports, but instead will use Unix domain socket files, which are similar to ports but live on the filesystem with explicit user permissions. Each HTTP server can be very simple, with no dependencies, because it doesn’t have to handle encryption, which instead happens at the SSH layer.
The apps can be conventional HTML-based web apps, but they can also be native outerframe apps.
I’ve built Outer Loop into an SSH browser for this type of graphical shell, and now I’m shipping an open-source Outer Shell.
Screencast: Outer Shell
Here I demo Outer Shell and how it works, and I try to give you a sense of how much low-hanging fruit there is in this space.
Documentation
Instead of writing an enormous blog post, I wrote a bunch of documentation:
Thoughts
Isn’t it weird that this doesn’t already exist? For browsers, capabilities like connecting to Unix sockets have been dismissed as extremely niche, but when you group it together with the right set of other capabilities (including SSH and sudo awareness), entire new branches of the tech tree become apparent. Instead of treating Linux (and other) servers as having conventional local graphical operating systems, we could focus on giving them “outer” graphical shells for remote devices. In an alternate timeline, we’d have been building out this ecosystem for decades, using conventional HTML / JavaScript apps. Many individual server-style web apps like Jupyter and Tensorboard did in fact appear, each with their own one-off security protocols, but nothing really arose to deliver them “correctly”.
And now, the opportunity is even bigger, because we can make the apps truly native. Now that we have AI that can help us write code, it is practical for each app to have a codebase for each target platform. I think this is becoming the natural architecture for the web: HTML for reading and casual apps, and native platform-tailored apps for getting work done. Why settle for less?
(Thanks to Rosanne Liu, Mirko Klukas, Adam Zethraeus, and Felix Andrews for reading/viewing drafts of this post and screencast.)