Mechs at Sea

We consider how large federated wiki sites could be cached and synchronized over short messages on slow or even intermittent connections. We are motivated by the challenges of ocean sailing but expect that there are many similarly challenging environments. matrix

The admin savvy sailor can cache whole sites onboard and then proxy dns to browse these while at sea. Public sites owned by the sailor can be updated from cache when they return to port.

I think I could design Mech blocks that could synch the cache over ham radio sending only Journal Actions.

Now you have me thinking about running Mechs server-side for all manor of low-bandwidth applications.

Here is how Mechs talk over the internet. A specific Mech is identified by site, slug and item id. A Mech that includes the GET or PUT blocks can both send and handle these requests. The sender is running client-side, the hander is run server-side.

A Mech will be connected to its twin when forked from the serving site. When the Mech runs the GET client-side, the nested blocks will be run server-side on the remote site. Similarly for PUT.

As an example we imagine an additional block, DELTA, that collects changes when run client-side and distributes changes server-side.

Sending the reverse direction uses GET and moves the two versions of DELTA around.

Note: the server-side handlers could be run by other applications, such as our own DATALOG, so long as they matched the protocol requirements. In this case the client-side run of the Mech is just a test that the endpoint is working as intended.

This implementation would be confined to the Mech plugin itself. We already support sufficient server-side routing to make this work. We've done other protocols as server-side plugins, notably the RSS plugin.

The ham radio connection I suggested above would be implemented on the live internet first and then bridged to Winlink Global Radio Email for operation at sea. wikipedia