Votebase is a governable server. What is a governable server and why would you want one?

Servers are computer programs that can send and receive messages, and can save long-term data in some kind of database. Servers are behind the operation of every website on the internet.

Normally servers are controlled by admins, some people that run the server and have complete control of what it does: what messages it can receive, what messages it sends in response, and what data it holds. A server admin can delete data or change the code of the server in any way they want.

Governance is when any group of people make and enforce rules in order to be able to live or work together. Any group of people that isn't actively warring has some set of rules, whether stated out loud or not, that allow them to coexist without violence. From as small as a group of friends playing a game, all the way up to nation-states and global politics, people are constantly negotiating what the rules are, what they should be, and who isn't following them. Governance is an inescapable part of being social creatures, because "rules" and "social systems" ultimately boil down to promises. The fundamental way we work together over time is by making promises to each other.

So how do "servers" and "governance" come together? Many smart people (opens new window) have pointed out that servers often create social infrastructure that changes how our society works. For example a social media site is a place where people share ideas, form relationships, and coordinate with each other, and the design of the site can massively shape and change those processes. This means that the way those servers are programmed to work is really important: a bad "system design" for social infrastructure can lead to really bad outcomes that no one wanted.

Unfortunately because of the aforementioned "server/admin" way almost all software is designed, in practice we have no choice but to accept that whoever runs the server gets to make all the decisions, no matter how disastrous they are, or how much the social system matters. (If the subreddit mod is a jerk, too bad, go somewhere else.)

This is the problem governable servers are intended to solve: what if the users of the platform, the "citizens" of this digital space, were the ones who decided how the servers work? What if they could change the rules however they wanted, and come up with whatever structures they thought would best let them achieve their collective goals? Not only would this help us build social infrastructure that won't decay over time (opens new window), but could open up possibilities for entirely new ways for people to coordinate. If people were allowed to "rearrange the furniture" of their digital systems (and maybe even build entirely new furniture), I'm willing to bet they would surprise us with a ton of useful and interesting ways to do so.

And this could absolutely go beyond digital spaces! Coordination systems are everywhere in society, from national governments all the way down to community gardens, and Votebase could be used to coordinate any of them. Such coordination systems could perform much better by virtue of being Automated to the greatest degree useful (opens new window), Evolvable, Modular, and Shareable.

The hope is that with the ability to easily create new kinds of coordination systems, cooperation between people that was previously too difficult or slow can actually happen, and different communities can experiment with new ways to work together productively and stably.

But building such a flexible system is hard! Software is usually built in the "server/admin" model for a reason: it's much more complicated to build server software whose behavior can be changed at any time even as it continues to operate.

This is the goal of Votebase: to design and build a system that has the promised flexibility while still being secure, fast, and robust.

Votebase's Conceptual Design

The design has these goals:

• Flexibility: The rules the server can encode shouldn't have any arbitrary limits, but should be able to do anything you could do in normal server software. This ensures we don't accidentally recreate "server/admin", since a community would be able to evolve the system using only the tools afforded by Votebase itself.
• Neutrality: The design of Votebase itself shouldn't make any assumptions about what kinds of systems people will implement. Whatever constraints Votebase itself imposes shouldn't unduly close off possibilities.
• Legibility: The way the server operates should be as clear and "figureoutable" as possible. It should be possible for server participants to understand what's happening with fairly little effort, and should be able to learn enough to contribute with a smooth progression of effort. (This one's really hard, as you'll see.)
• Robustness: The server shouldn't allow proposed changes that would obviously break everything. It's impossible to prevent all kinds of failures or breakdown, but we should use all the tools granted by computer science, such as type checking (opens new window) and permissions checking (opens new window), to defend the coherence of the system.
• Scale Readiness: Scale is an unavoidable part of the real world, and it is often the case that systems that are capable of working at large scale have advantages that smaller ones simply cannot achieve. A governance server should be designed with the assumption it could succeed and end up being used by huge groups of people.

These goals have influenced the set of affordances (opens new window) or abstractions (opens new window) that I think a good governable server design should have.

Below are the actual core concepts.

Polity

A Votebase server represents some Polity (opens new window), some group of people with shared goals and the desire to coordinate to achieve those goals.

Member

Every Polity has a list of Members, people who are allowed to interact with the server. Votebase provides facilities for people to be added to a Polity, create and manage an account, and securely log in.

Fully enabling end-to-end encryption (opens new window) or anonymity at the Runtime level is considered out of scope for now, but it's possible to achieve those goals within the capabilities offered.

Ruleset

The most important concept is the Ruleset. It is the fundamental unit of governance code that can be interacted with and changed.

Polities can have many Rulesets, enabling the Polity to divide up decisions and sub-systems in any way they wish.

A Ruleset contains a few pieces of code/data that determine how it behaves. The technical implementation section describes the finer details.

• The Data Schema is a declaration of what kinds of data it can store and how.
• The Action Functions can be called by Members to alter the data stored by the Ruleset.
• The View Functions can be called by Members to see the data stored by the Ruleset.
• The Events are possibly recurring scheduled times when some particular Action should be executed.

The Action and View Functions have access to the Votebase Runtime (opens new window), which is a catalog of functions the Rulesets can use to add or remove Members, access the database, send messages to other servers, or make changes to Rulesets or Events.

Rulesets can use the Runtime to replace themselves, which is the core mechanism for how a Votebase server changes over time. Actions can call Runtime functions to propose a replacement for their containing Ruleset, or initiate the actual replacement for a previous proposal. The Runtime will ensure that any proposed replacement is "coherent" given the state of the whole server, and reject replacement proposals that would obviously break things.

Rulesets can reference each other, meaning they can reference data stored by others, or call functions defined by others. This is to allow for the possibility of sub-systems that can "interact" or "collaborate", such as when a county election process references a national election in order to administer it. Any structure of subsidiarity (opens new window) or delegation can be constructed using Rulesets and references.

A Ruleset can also have Children, subsidiary Rulesets that it can manage. This means Rulesets form a tree (opens new window), which always has a single "root" Ruleset that holistically forms the foundation of the entire server. This tree system, along with a set of reference rules, ensures Rulesets can reference each other while still maintaining Robustness and Legibility.

The Ruleset Tree

At first glance the tree system seems to impose a non-Neutral "hierarchical/top-down" structure on all Votebase servers, but I'll explain why this isn't true after detailing the reference rules:

• Parent Rulesets have the power to delete or replace child Rulesets.
• Rulesets can reference each other, using either Strong or Weak references. The Runtime will prevent Ruleset changes that would invalidate a Strong reference, but not a Weak reference, so Rulesets that make Weak references must account for the possibility they could not exist.
• A Ruleset can only have Strong references to its direct lineal ancestors (parent, grand-parent, etc).
• A Ruleset can have a Weak Reference to any other Ruleset, including a descendant.

This system of rules ensures that there are never any Gordian knots (opens new window) of Rulesets. Specifically, the system ensures it's always possible to change a Ruleset without changing some other Ruleset first.

Allowing Rulesets to strongly reference each other arbitrarily would allow situations where a Ruleset can't change itself because some Ruleset it has no control over is referencing it, which could be used as a form of "reference attack". Every strong reference can be dealt with by possibly destroying the descendant Ruleset that has the reference, because by definition the referenced Ruleset has the power to alter or destroy the ancestor referencing it.

The presence of Weak references is why Votebase doesn't impose any particular governance structure. Because Weak references can be made between any Rulesets, any graph structure (opens new window) of collaborating Rulesets can be constructed, but we still have a Robust and Legible system that won't get "stuck" in a hyper-tangled state.

This bias toward Robustness I suppose could be a form of non-Neutrality, by granting added guarantees to tree-like systems, and their rigor of holistic (opens new window) composition. But it seems to me worth the small sacrifice of Neutrality. Feel free to fork Votebase and experiment with different reference rules!

The Holistic Root

You may ask: doesn't the "root" system impose a particular governance structure? This is a more complex question, but the answer is also no.

To show why, let's imagine we had a system where there could be many "root" Rulesets, meaning ones that don't have a parent. My question is: How should the community decide what those root Rulesets are? Answering this question forces us to ask the "recursive" governance question: "how do we decide how we decide?"

We fundamentally can't escape this recursion. At every level, for any answer we come up with, we could keep asking the question at the next level up. This means the only way to escape having to endlessly make assumptions is to make a single base-case assumption: every Polity has a single founding root Ruleset. When a Polity is started, some initial root Ruleset is seeded, which is then iteratively used to make all other decisions.

This leads us to the painful truth of any self-evolving system of rules: it's possible for a system to hit a permanent dead end! (Called a softlock (opens new window) in the world of video games.) If a root Ruleset can no longer be reasonably evolved using its own rules, we have no choice but to abandon it and start something new (a new Polity with a new founding Ruleset). We must "plant a new root" that we more carefully design to not meet the same fate. It's impossible to avoid this fate without using advanced logical proof systems (opens new window), which would be profoundly complex and Illegible. And even with such logical guarantees, there could still be social reasons why a system will forever remain stuck.

Demanding a single root Ruleset has the mathematical virtue of parsimony (opens new window), in that it's as simple as it could be while still allowing all desired outcomes. In order to allow multiple root Rulesets as a basic concept of Votebase, we would have to choose some system for how they should be added, and that itself would be a non-Neutral assumption! The holistic root system allows any more particular system to be defined within it.

Ruleset Sharing

A core intention of this project is to allow Ruleset definitions to be reusable, so a Ruleset written and validated by one community could be repurposed for another community.

Since Rulesets can reference each other, this means there has to be a way for Rulesets to remain "abstract": after all, a Ruleset is only truly "reusable" if it doesn't "hard-code" the Rulesets it references. So the Votebase project has tooling to write Rulesets that don't reference any particular Ruleset, but instead merely reference "typed variables" from other Rulesets that can be filled in later.

I predict the Votebase ecosystem will be shaped like most open source communities, with a relatively smaller number of "library authors" writing almost all of the Rulesets that are then leveraged by more casual participants.

Toward a New Era

All of human success and prosperity is built on working together and coordinating our actions. This project hopes to enable a new era of rapid experimentation to improve our governance in every way. It's a foundation for a what I hope will be a thriving village square of new ideas that will outpace my wildest imagination.