Distributed Administration Network
From Metagovernment - Government of, by, and for all the people
A Distributed Administration Network (DAN) is a concept for removing control of a computer system from a single person, in accordance with the principles of collaborative governance. It requires a minimum of three (and preferably many more) computers all running an identical server application (these are called instances). The concept is very closely related to a computer cluster except that in a cluster, all member computers (nodes) are administered by one person.
In a DAN, each instance is administered and maintained by a separate administrator or administration group with unique passwords. Thus any administrator can only manage their own instance and not others in the DAN. The DAN itself is formed ad hoc by administrators joining their instances together using a DAN protocol.
The member instances of a DAN coordinate with each other through software mechanisms (e.g., hashes) to validate that they are still running the same instance.
When new data is introduced to one instance (as when a user creates or modifies a record), that data is then replicated to other members of the DAN which accept that instance's hash. This process is similar in basic concept to a redundant cluster, but again, with distributed administration.
When an instance fails to properly conform to the hash or other checking-mechanisms, it is deprecated from the network. It can continue to run, but new information is not replicated between it and the DAN. This concept is similar to a fork in software development. It can be a result of an accident, deliberate tinkering, or a deliberate fork. In the last instance, an administrator may think that the DAN is not run properly and sets us a fork in the hopes that other administrators will replicate it into a new DAN.
This idea is still theoretical (as far as we know) and was developed on the Metagovernment Startup list in order to address the question of corruption in administrators (or other possible causes of failure in a single-server system).
There are numerous technological and conceptual hurdles (e.g., how to perform software upgrades without breaking the DAN; avoiding severe performance problems as the DAN scales to many instances, etc.), but the basic concept appears feasible as it is mostly just an extension of existing technologies.