Three layers of federation

The Federation can be viewed as an interlocking set of layers that support decentralisation and federation.

Here we look to think more deeply about how these layers interact, and if they are all necessary to achieve the architectural aims of the federation.

Here we describe the The Federation. We should use this term wisely. It describes quite clearly the social aspects of this project, while also pointing gently towards Star Trek and the future of the Decentralised Web.

Thoughts on the future architecture of a permanent internet archive, and how we can start in small incremental steps.

We expect some pages to be more mobile in the federation than others. With statistically significant flows between neighborhoods we will have the opportunity to separate ideas from their carriers based on affinities that we need not know in advance.

Should each person who is in interested in making their holochain fed-wiki server part of the federation by creating a public gateway, be responsible for running their own servers?

Spam in The Federation is much less of a problem than it is for Quiet Wiki's. Fork Spam and Fork Privacy remain real issues, as they do for instance with blogs and Comment Spam, or more genrally Link Spam.

A federated wiki DApp would combine the flexibility of wiki federation, with the robust decentralised power of the Blockchain.

What format should we save our data, and code in the Federation? We look for the following properties and qualities for any solution we choose:

We consider the risks of building federated wiki or anything else permanent on something as fragile as information.

A federated-wayback-machine, is a way of archiving all content in the Federation. JSON from every site would be periodically archived in a decentralised manor.

Federated servers are a tried and tested basis for decentralised cooperation on the internet. Email is the classic example of such a federated architecture. Federated wiki reinvents this federation in a minimal way for web sites. Each minimal wiki-server provides an entry point into the federation, while maintaining only the smallest possible code base, relying instead on browser-based federation to work it's magic.

Pure javascript in the browser, combined with CORS headers, enables federation of content and services leveraging only the browser.

Here we look at various approached to archiving wiki content. Sites come and go. People lose interest, or let them domains lapse for one reason or other. When this happens we lose this content from the federation - save for those pages you have forked for yourself to your own site.

Here we collect notes and ideas about how The Federation should evolve - where it is going. See Changes to the Future.

A co-operative federation or secondary co-operative is a co-operative in which all members are, in turn, co-operatives. Historically, co-operative federations have predominantly come in the form of co-operative wholesale societies and co-operative unions.

When we are thinking about data in the federation we are talking about people curating there own data sets by embedding Live Data or Static Data as JSON Data Objects into one of their Federated Wiki Pages.

Here we explore governance in the particular context of governing a commons, that is an organic federation or ecosystem of decentralised entities.