REPL Ideas for GoActivityPub

The way GoActivityPub services function at the moment in respect to having any maintenance tasks performed by the site operator is by using a “control” binary that sends a signal to the server and then effectuate the changes.

The main reason for this method is that we treat our storage backends as not supporting multi process access (for most this is not a requirement, but it’s better to be safe than sorry) and we need to interleave the normal operation of the service with the maintenance tasks.

This is not a great solution as signal passing isn’t very efficient, it isn’t very pretty - we need to send two signals, one to lock and one to unlock storage. Additionally, while the maintenance task is running, the users are faced with an out of order response because the service’s storage backend is no longer available. If the signals fail to be processed correctly for some reason, the server can remain in an inconsistent state that needs further handling. Overall not a very robust and user friendly user experience.

So, in order to change this, I want to introduce a method I cribbed from Stegodon’s implementation, which uses an SSH server where a user (or a script) can authenticate and run commands exposed by the custom implementation.

So I’m thinking to expose the existing commands of the control binary as commands in a REPL environment, or eventually, a TUI (for which we already have some elements up and running)

The end result would be that a site operator can ssh at a specific address for the server, a Bubble Tea interface would pop up and they would be able to run commands in a REPL environment or, in the case of the TUI, be presented with it directly.

This environment would fully run in the same process as the service itself, so no more need for interleaving access to the storage backend, decreasing friction for both operator and users.