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.
Facebook's ad platform famously uses the Vickrey–Clarke–Groves auction [0]. In theory it rewards advertisers for bidding for ads using their true valuation, or rather, the lifetime value of a customer.
In practice, it's a lot more convoluted, but the basic principle is fascinating.
Combining Swagger (OpenAPI) with Markdown prose was what prompted us to build Doctave [0]. Jekyll does a good job, but breaks down once you need more bells and whistles, such as search and versioning.
So first, alter server state before transmission by spawning hallucinations (human-like bots) in places not visible to human players (inside walls, unusual angles, far in the horizon). To the client, they all look like human players. At least in memory.
The players who react or interact with these hallucinations are likely cheating.
This flips the roles, and the hard task of correctly determining "human like" behaviour is now on the cheaters.
The players who react to fake enemies self-identify as cheaters.
[1]: https://www.activision.com/cdn/research/hallucinations