Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

Post reply on HN
Print view View original

31–40 of 239 posts

Re: A native graphical shell for SSH

#31

Post by nativeit »

nativeit wrote: post #20

I thought this looks interesting, but was a little confused with what appears to be MacOS-only support at 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?

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.

Re: A native graphical shell for SSH

#33

Post by mrcslws »

trashb wrote: post #24

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 WebS…

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

Re: A native graphical shell for SSH

#34

Post by KomoD »

_def wrote: post #27
purplehat_ wrote: post #14

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,…

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"

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"

Re: A native graphical shell for SSH

#37

Post by abnercoimbre »

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=...

Re: A native graphical shell for SSH

#38

Post by mrcslws »

setheron wrote: post #32

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?

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).

Re: A native graphical shell for SSH

#40

Post by Natfan »

KomoD wrote: post #34
_def wrote: post #27

Earlier quoted context omitted.

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"

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"

does this work with multiple caddy servers? ie can you bind multiple caddy servers to port 80/443?
Post reply on HN