I have been experimenting with similar idea myself. I was curious on how you handle instantiating the terminal state for new clients. Seems like you're storing a buffer [0] of past output, and replaying that?
ScaleSocket is a command line tool that lets you to wrap any STDIO capable script or binary, and serve it over websockets. Clients then connect to rooms (channels) which have an unique URL (wss://example.com/exampleroom). Connecting to a room spawns a new process of the wrapped script. Subsequent websocket connections to the same room share the process.
I built ScaleSocket in order to be able to build multiplayer back-ends quickly. In the past, I have been experimenting with websocketd [1] to stream a command line application to the browser. It seemed to me that using that approach, i.e. spawning a process and streaming it over websockets, would make a nifty back-end for browser based multiplayer games. ScaleSocket takes that one step further, by supporting shared backend processes.
It's a pleasant approach to get started with, since no lobby server or netcode is required for making a multiplayer backend. ScaleSocket has been my prototyping tool for multiplayer games for some time now.
It's similar to running netcat in server mode, wrapping a script. It's even closer to doing that using websocat [1], whereby one does not have to do the websocket header juggling.
The main difference is that while netcat or websocat will spawn a new process for each connecting client, ScaleSocket has a concept of rooms (channels). For a room, a process is spawned once only. All clients connecting to the same room are routed to the same process. This is not straight forward to do using the forementioned tools.
There's a small comparison page [2] where I have mentioned some alternative tools.
I've been developing a websocket server that lets multiple users connect to the same command-line app.
I wrote a short example [1] that exposes a TUI game on the web. In theory, hot-seat terminal games should be playable over the web with this.
My current challenge has been around refreshing the screen for late joiners. I need to save some of the ANSI escape history and replay it to clients, or ask the application to redraw itself. If anyone has ideas on how to approach this i'm all ears.
I was eager to try this. The screenshots had me convinced the workflow would resemble Alfred/Spotlight. Be careful of guessing your users workflows - there are a lot of ways using git. It seems opening the commit window stages all changes. I'm used to working with patches (`-p`), so in in it's current form it wont suit my workflow.
[1]: https://github.com/seanmonstar/warp