4 ms·

Sounds like a similar family of problems to [Wish](https://github.com/charmbracelet/wish https://github.com/charmbracelet/wish) by charm.sh. They've been pushin

Sounds like a similar family of problems to [Wish](https://github.com/charmbracelet/wish https://github.com/charmbracelet/wish) by charm.sh. They've been pushing this curious paradigm of "ssh apps", where ssh keys are used to automatically create identities for small self-hosted CLI/TUI apps. As a useful comment for messh, it looks like you've committed the ssh_server binary file to git; you may want to add that to gitignore, as binary file handling isn't a traditional git strength. I _think_ it's better than it was a decade ago when I last investigated this, but I can see that Pro Git still recommends explicitly setting gitattributes to mark a file as binary https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Binary-Files https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...

akshayKMR 2y ago
Regarding ssh-apps, this seems super duper niche to me even for developers. Like, I get that many devs are terminal savvy, and it's cool that it's possible to serve apps like this but is it practical (to pick for your new product /internal app)?
- qudat 2y ago
  We are pretty successful over at https://pico.sh https://pico.sh using the same techniques — and using wish
- latchkey 2y ago
  As a bare metal cloud service provider, we built a little TUI app over ssh so that people could upload their public keys to us without having to use a web interface. It has worked out really well because it makes it possible to "upload" the public key without having to do anything but login. We automatically configure ssh on the servers to auth against our own internal api for serving up the keys. This way, customers can add to authorized_keys and also use our TUI for management as well.
- hamandcheese 2y ago
  As a developer, I agree. Give me a great CLI, please, not a server rendered TUI. This gives me another thought though, a "server-rendered" CLI. A tiny shim binary that just sends argv to the server, and the server sends back stdout/stderr. Haven't seen anyone try that.
  - gwynforthewyn 2y ago
    That sounds very similar to the command form of ssh i.e. "ssh foo.example.com ls" :)
  - messh 2y ago
    a "server-rendered" CLI is exactly what `keypub.sh` is, and what many ssh apps are (some are more TUI)
    - hamandcheese 2y ago
      Yeah, in retrospect, I'm an idiot. I wasn't considering `ssh foobar.io dothething` to be equivalent to what I was thinking in my head even though it is exactly equivalent.
- bradgessler 2y ago
  I'm working on a different approach that doesn't use ssh at https://terminalwire.com/ https://terminalwire.com/. It's meant for inherently server-based CLI's like Github, Stripe, Fly, Heroku, or any other SaaS and can be plugged directly into web frameworks. My thinking is that more companies would ship command-line interfaces if they didn't have to maintain APIs for them, deal with distributing binaries (and all the compatibility issues that come with that), or deal with all the configuration involved in hooking up SSH to their app servers. It's in beta at the moment, and I'm currently focused on Rails apps to get the ergonomics dialed-in. My goal is to make it possible for people in any web framework to build and ship a CLI to customers in under an hour and never have to touch an API or worry about binary distribution for as long as their CLI exists.
  - qudat 2y ago
    At my org the biggest issue with out CLI is not the initial distribution, but supporting and maintaining multiple platforms, code signing the binaries, and making sure customers actually update the binaries.
    - bradgessler 2y ago
      Yeah, I put all of that under the umbrella of “distribution”—the last mile is a huge pain in the SaaS that SaaS CLIs shouldn’t have to deal with or even think about. Terminalwire will handle the builds for all the different platforms, signing, etc. so companies can instead focus on shipping their unique features to customers. I’m also going to ship clients that automatically update to match the version of the client that’s compatible with the server in a way that the client won’t even notice.
      - darthwalsh 2y ago
        At the large enterprises I've worked at, signing with our certs had to happen on our own build machines. And I don't think there was any precedent if we could sign third party binaries that had been built for us. Having some my-company.terminalwire.com as the signing identity could work; I bet most SMB wouldn't bat an eye to ship like that.
messh 2y ago
hi, good catch of the binary! (will fix) `Wish` and also `terminal.shop` were both great sources of inspiration. I hope to see many more ssh apps in the future. I'm already working on the next one
ilyagr 2y ago
Another interesting set of ssh apps is https://pico.sh/ https://pico.sh/ . These focus on networking and lightweight hosting (pastes, simple blog), all via ssh or rsync.
theamk 2y ago
Looking at their demos immediately brought back the memories of parsing TUI's using ad-hoc "expect" rules. I honestly don't get the point of TUIs... A real command-line interface is extremely useful - it's trivially scriptable, works direct or with ssh, scroll-back buffer logs what happened, commands stay in my shell history, I can copy-paste commands to a friend over chat system, or into shell script, and it's easy for app authors too. Its my first choice for my apps. If low-color fixed-width character grid is not cutting it, then native app or web app is a great second step, or even intermediate solutions, like generating HTML files from CLI tool and opening them in default browser. You have to invest some effort, but you have infinite ways to design your interface, and it's still in user's familiar environment. But those charm.sh TUI applications seem utterly useless and highly annoying. They give up all of the terminal advantages: my shell's history is useless, my favorite ways to edit commands does not apply (as they have their own editor), I cannot scroll back and see what the program just printed, I cannot script it, I cannot log it, I cannot search it, I cannot redo the previous action, the color scheme is not the one I've picked... At least with web apps I can parse html and/or hit underlying API directly - no such luck with TUI apps. At least the good news is that TUI apps are not getting any traction, and I can completely understand why.
- PhilippGille 2y ago
  > At least the good news is that TUI apps are not getting any traction, and I can completely understand why. lazygit (54k stars on GitHub) and k9s got a lot of traction and are very popular: https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit https://github.com/derailed/k9s https://github.com/derailed/k9s
- darkwater 2y ago
  I totally agree with you, I prefer good autocomplete to a TUI for all these reasons (and more). Well, I actually prefer any CLI to a TUI. The most TUI thing I use in my toolkit is `top` (yes, the "classic" one)
- houzi 2y ago
  TUI's have one thing going for them: Copy paste anything! IntelliJ doesn't let me copy any text it shows me. Also, TUI's have their place. I haven't looked much at GUI alternatives, but k9s is really great. Would also assume that interactive apps are simpler to implement if it's a TUI.

akshayKMR 2y ago

Regarding ssh-apps, this seems super duper niche to me even for developers. Like, I get that many devs are terminal savvy, and it's cool that it's possible to serve apps like this but is it practical (to pick for your new product /internal app)?

qudat 2y ago
We are pretty successful over at https://pico.sh https://pico.sh using the same techniques — and using wish
latchkey 2y ago
As a bare metal cloud service provider, we built a little TUI app over ssh so that people could upload their public keys to us without having to use a web interface. It has worked out really well because it makes it possible to "upload" the public key without having to do anything but login. We automatically configure ssh on the servers to auth against our own internal api for serving up the keys. This way, customers can add to authorized_keys and also use our TUI for management as well.
hamandcheese 2y ago
As a developer, I agree. Give me a great CLI, please, not a server rendered TUI. This gives me another thought though, a "server-rendered" CLI. A tiny shim binary that just sends argv to the server, and the server sends back stdout/stderr. Haven't seen anyone try that.
- gwynforthewyn 2y ago
  That sounds very similar to the command form of ssh i.e. "ssh foo.example.com ls" :)
- messh 2y ago
  a "server-rendered" CLI is exactly what `keypub.sh` is, and what many ssh apps are (some are more TUI)
  - hamandcheese 2y ago
    Yeah, in retrospect, I'm an idiot. I wasn't considering `ssh foobar.io dothething` to be equivalent to what I was thinking in my head even though it is exactly equivalent.
bradgessler 2y ago
I'm working on a different approach that doesn't use ssh at https://terminalwire.com/ https://terminalwire.com/. It's meant for inherently server-based CLI's like Github, Stripe, Fly, Heroku, or any other SaaS and can be plugged directly into web frameworks. My thinking is that more companies would ship command-line interfaces if they didn't have to maintain APIs for them, deal with distributing binaries (and all the compatibility issues that come with that), or deal with all the configuration involved in hooking up SSH to their app servers. It's in beta at the moment, and I'm currently focused on Rails apps to get the ergonomics dialed-in. My goal is to make it possible for people in any web framework to build and ship a CLI to customers in under an hour and never have to touch an API or worry about binary distribution for as long as their CLI exists.
- qudat 2y ago
  At my org the biggest issue with out CLI is not the initial distribution, but supporting and maintaining multiple platforms, code signing the binaries, and making sure customers actually update the binaries.
  - bradgessler 2y ago
    Yeah, I put all of that under the umbrella of “distribution”—the last mile is a huge pain in the SaaS that SaaS CLIs shouldn’t have to deal with or even think about. Terminalwire will handle the builds for all the different platforms, signing, etc. so companies can instead focus on shipping their unique features to customers. I’m also going to ship clients that automatically update to match the version of the client that’s compatible with the server in a way that the client won’t even notice.
    - darthwalsh 2y ago
      At the large enterprises I've worked at, signing with our certs had to happen on our own build machines. And I don't think there was any precedent if we could sign third party binaries that had been built for us. Having some my-company.terminalwire.com as the signing identity could work; I bet most SMB wouldn't bat an eye to ship like that.

messh 2y ago

hi, good catch of the binary! (will fix) `Wish` and also `terminal.shop` were both great sources of inspiration. I hope to see many more ssh apps in the future. I'm already working on the next one

ilyagr 2y ago

Another interesting set of ssh apps is https://pico.sh/ https://pico.sh/ . These focus on networking and lightweight hosting (pastes, simple blog), all via ssh or rsync.

theamk 2y ago

Looking at their demos immediately brought back the memories of parsing TUI's using ad-hoc "expect" rules. I honestly don't get the point of TUIs... A real command-line interface is extremely useful - it's trivially scriptable, works direct or with ssh, scroll-back buffer logs what happened, commands stay in my shell history, I can copy-paste commands to a friend over chat system, or into shell script, and it's easy for app authors too. Its my first choice for my apps. If low-color fixed-width character grid is not cutting it, then native app or web app is a great second step, or even intermediate solutions, like generating HTML files from CLI tool and opening them in default browser. You have to invest some effort, but you have infinite ways to design your interface, and it's still in user's familiar environment. But those charm.sh TUI applications seem utterly useless and highly annoying. They give up all of the terminal advantages: my shell's history is useless, my favorite ways to edit commands does not apply (as they have their own editor), I cannot scroll back and see what the program just printed, I cannot script it, I cannot log it, I cannot search it, I cannot redo the previous action, the color scheme is not the one I've picked... At least with web apps I can parse html and/or hit underlying API directly - no such luck with TUI apps. At least the good news is that TUI apps are not getting any traction, and I can completely understand why.

PhilippGille 2y ago
> At least the good news is that TUI apps are not getting any traction, and I can completely understand why. lazygit (54k stars on GitHub) and k9s got a lot of traction and are very popular: https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit https://github.com/derailed/k9s https://github.com/derailed/k9s
darkwater 2y ago
I totally agree with you, I prefer good autocomplete to a TUI for all these reasons (and more). Well, I actually prefer any CLI to a TUI. The most TUI thing I use in my toolkit is `top` (yes, the "classic" one)
houzi 2y ago
TUI's have one thing going for them: Copy paste anything! IntelliJ doesn't let me copy any text it shows me. Also, TUI's have their place. I haven't looked much at GUI alternatives, but k9s is really great. Would also assume that interactive apps are simpler to implement if it's a TUI.