I use fish shell ><> because it's really good for both interactive use and scripting. Thanks fish developers!

I'm planning to use it to write scripts in future because it's fun.

The way this will work is the main instance will be connected to a GitHub webhook, which will send a request to the server when a new commit is pushed. The main server can then broadcast to all connected clients that there is a new update. I think this will be very good for getting updates straight away.

Clients can connect to the main instance using event streams, which is basically just a stream of almost-plaintext over HTTP. This means it's instant, unlike polling, and it's uncomplicated to use on the command line, unlike something like websockets.

I do realise that this might be a bit over-engineered, but I think it's better than the alternatives:

• RSS feeds (does GitHub have RSS?) The thing with RSS is that the full content is sent each time, so I'd have to add everything to some sort of store on disk and check against that store. Possible, but I think it could get messy. RSS is also a few minutes slow because it's polling, though this doesn't matter.
• A webhook connected to each instance. This would require the server to be directly addressable on the web (private instances behind NAT are not). Also, GitHub doesn't let you set up webhooks if you aren't a manager of the repository.

So that's why I've chosen this system. Let me know if you have an idea which would be better.

Lots of thinking today.

— Cadence