Let’s Design A Network State — Part III: Messaging, Petitions, Sortition, Elections and Relaying

I am moving on from the topic of the citizenship primitive, which is important, but it is not the most important element of my design. Today, I am going to focus on the “main course.”

After examining DAOs, corporations, countries and startups, I have come up with the simplest possible conception of how to design and implement a minimum viable network state.

It begins with a messaging bus.

Universal Network Messaging

For a network state to function, citizens and the groups, councils, juries, and other bodies within the Network State must be able to communicate. There must be a common means to dispatch, subscribe and recieve messages.

These messages can include the following:

• Requests for help
• Submissions of proposals
• Submissions of votes
• Broadcasts of messages or news
• Broadcasts of results of elections or rulings
• Submissions of complaints or petitions
• etc

A network state cannot offload it’s communications to external bodies like Facebook, Twitter, Telegram or Discord. A Network State must have it’s own sovereign message passing system or it can be taken offline.

Communications Risk and Communications Fragmentation

The common communications bus must exist as the first thing built in a Network State, even before the Citizenship Primitive. The reason is simple: Today, DAOs and communities are highly fractured across Discord, Telegram, Twitter, Email, Meetings, SMS, Signal and so on.

Organizing a network state requires garaunteed ability to reach citizens with messages they need to hear and respond to. This might take the form of a dedicated application Citizens are required to download.

In other words: The communications framework to launch a network state is absolutely essential and it can’t be “cobbled together” across dozens of platforms. There must be a single, canonical, unified way to communicate on official business.

Messaging Queues, Subscriptions, Routing

All Citizens should be able to subscribe to the universal messaging bus and receive messages dedicated for them. A core objective of a Network State, and part of the source of it’s efficiency is that all communications are digital native.

The ultimate goal of a Network State is total engagement and participation. This means 100% participation in every single vote, among other things. This is only achievable if Citizens are able to subscribe to the message bus and have requests relevant to them routed to them.

Forms of Message

Everything in a Network State is the result of messages passed over the universal messaging bus. If someone wants to request money, it goes through the pipes. If someone wants to file a lawsuit, it is done by submitting the appropriate message over the wires. If someone wants to request a ruling on some point, a jury or panel is formed automatically when the appropriate request is submitted to the messaging bus.

Here are a list of API calls that are reasonable to expect:

• Form Jury
• Form Panel
• Submit Vote
• Change Vote
• Submit Ruling
• Revoke Citizenship
• Mint Citizenship
• Submit Proposal
• Revoke Proposal
• Revise Proposal
• Vote Proposal
• Delegate Vote
• Elect Official
• Impeach Official
• Send Message

Etc.

In other words, the total API of the Network State may be modeled as a list of messages passed within the system. Different messages will include different payloads such as an attached proposal.

The Network State requires a message-passing based design similar to patterns found in large UI systems that rely on dependency injection.

Dynamic Government (Realtime Governance)

One of the biggest flaws in the governments of the world is the slowness of bureaucratic processes. Legal rulings, Jury Selections, budget rulings, votes and other processes take far too long.

In fact, our legal system is so broken most lawyers try to avoid it altogether because the Jury system is known to be so flawed. In a functioning democracy, Juries would be trusted to rule on issues. In most countries, Juries are to be avoided like the plague.

Likewise, votes and elections are highly questionable. From the outset, a network state is designed to ensure maximum speed and efficiency.

Dynamic Sortition and Queues

My network state design relies on a structure of Queues and Dynamic Sortition. Dynamic Sortition is the process of rapidly choosing a panel to rule on some issue or another which can be called at any time.

Citizens of the Network State are free to submit proposals, greiviences, requests and petitions in real time. Dynamic Sortition instantly selects from the Citizen body a group of individuals who are then empowered to make binding rulings on these requests.

Dynamic Sortition allows a government which moves extremely fast and can make decisions and adapt to conditions extremely fast. Dynamic Sortition allows extremely rapid rulings.

Queues are lists of proposals, grievances, petitions and requests for help which are all eligible to be resolved via Dynamic Sortition.

Avoiding Proposal Spam

A nominal fee should be attached to the cost for submitting a petition request or anything that results in Dynamic Sortition. There should also be network speed limits and prioritization of requests.

Similar to the backlog of the Supreme Court, the dynamic sortition process of a thriving Network State might be overloaded. Assuming there are enough qualified citizens, it should be possible to handle them all. On the other hand, bad actors coordinating together might attempt to overwhelm the system with requests. These are problems for later and could be solved at the level of an intelligent router that filters requests for legitimacy before routing them.

Elections

In a traditional government, officials can be elected to various posts and positions. These posts and positions provide powers and responsibilities to those officials. In a network state, positions should be elected who are empowered to carry out various projects within the Network State.

It should be possible to submit a request to “mint” a novel representative at any time to perform some purpose and Network Citizens should be able to view the proposal and vote on it.

If Elected, that official has some time-limited capacity to engage in some sort of work on behalf of the Network State. Unlike a traditional state, I am imagining a world where a Network State can rapidly adapt to conditions by inventing new titles and jobs as needed.

For example, should the network state desire to organize a summit for itself, an election might be held which empowers an event organizer and provides them with a budget to spend.

Volunteering and Service

The same messaging and queuing system can be used to submit notifications of service or to request help from the Network State. This “Service” can be performed by any Citizen who accepts the message and fulfills the task.

This in turn builds their citizenship score.

Summary

Once again, this is an abstract architecture which might be built in any number of ways. My objective here is merely to document what is required so some future builder might undertake the project.