Reclaiming Servers

There are several ways of using decentralized technology to create the federation. The first and current way that has been prototyped in federated wiki is to place all the logic in client-side javascript. Let's call that technique browser-based federation. The second technique is to federate the servers. We need a new software stack for servers if they are to contribute to the federation.

Platform Earth aims to create a sustainable suite of microservices for the commons. The community of providers so conceived, serves both json, static html5, and federated microservices. Here we look at how we might provide servers for this content in a pragmatic way that aligns with the decentralized architecture that we envisage.

# Decentralisation

Our argument is that decentralization is a social and political process, not simply a technical one. A technical architecture will revert to a centralised one, should this be supported by conventional market incentives.

Pure P2P technology stacks, provide us tools with which we can Redecentralize the web. However they do not provide the full social stack. For that we need both pragmatix, and a path towards that end - not simply tools that facilitate the end goal.

# My server

For a server to meet these needs it needs to be as easy to run and maintain as any conventional software package - say a word processor. And just like a word-processor it needs to run locally, or to be more precise it needs to be Owned.

That is the server must have an owner that is empowered to run their application wherever they feel they would like it - either on their laptop, their mobile phone, or in The Cloud. It is only then that the psychological and social incentives will be aligned to support real federation, and data privacy.

# A docker in my pocket

Docker provides us with a technical infrastructure on top of which we can build a federated server based architecture that is flexible, and supports continuous deployment of services. The very same server can then be run and maintained on the desktop as well as the cloud.

Using docker as a form of package manager for a desktop server, may not be a conventional use of the technology, but in reality it is simply an extension of the current use of dockerisation to provide a local development environment.

A container based federation server has a number of advantages over simply using a local javascript based server or electron client when considering running a local server:

1. We can take advantage of containers to provide us with optional layers of functionality 1. We can leverage development pipelines to enable continuous deployment of software services 1. Distribution is simply a matter of distributing light-weight (docker) text files 1. Single code base for servers, desktop and decentralised apps.

# Clusters and loose-coupling

Containers enable a loose-coupling of services to the federation. Instead of a single server, we can envisage multiple types of server providing different specialised services to the federation. Each server can be built using it's own appropriate software stack.

Such containers can then be composed into single deployable entities or broken up into separate server clusters enabling a range of ways to scale and deploy services.

# Possible drawbacks

We may not be able to push this line too far. Container based, docker based installation may be cumbersome, and the need for a full server based stack including the operating system, may be overkill.

However based on current experience of developing plugins for fedwiki using this environment, and the potential for fast and automated builds, this avenue looks promising.

Given a suitable container based format, there is nothing to prevent compilation pipelines that are able to create native applications on the various platforms from a central core container based image.

# Conclusion

Container based federation hosting looks like an excellent way forwards in terms of building a more robust, scaleable, and sustainable architecture for the federation.

Only practical experience will tell if the toolchains used prove to be more of a burden than conventional package managers.

Certainly when we look to include services from a range of existing code bases, having the ability to leverage them outside of the javascript work has advantages.

Either way, the federation requires a more flexible server based architecture, pure javascript pipelines inside of the browser are cool, but the tried and tested client-server based architecture of the web, points to the fact that a dialogue between servers and clients is still likely to have a role in the federated future.