paint-brush
Modpol is a Self-Governance Toolkit for Communities in Online Worldsby@ntnsndr
997 reads
997 reads

Modpol is a Self-Governance Toolkit for Communities in Online Worlds

by Nathan SchneiderJanuary 30th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Modpol is a self-governance toolkit for communities in online worlds. We are creating the first implementation in a multiplayer game called Minetest.

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Modpol is a Self-Governance Toolkit for Communities in Online Worlds
Nathan Schneider HackerNoon profile picture


Modpol is a self-governance toolkit for communities in online worlds. We are creating the first implementation in a multiplayer game called Minetest.


Consider a group of friends meeting for a picnic in the park. How do they make decisions, such as where to lay down their blanket, or when the rain becomes too much? Easy, right? They read each other's gestures, they hear each other out. Some of the friends might have more sway than others, but even they adopt the assumption that the goal is to make most everyone happy and prevent anyone from feeling really left out.


The rain becomes too much, in the end. They split up, go home, and meet on—well, take your pick: Discord, Facebook, Instagram, WhatsApp, or whatever. They're the same friends, with the same basic instincts to watch out for each other. But now, weirdly, one of them is the admin of their online group, just because she happened to set it up. She alone can censor and remove people at will, change the group settings, change how their interface looks—the works.


Maybe this is fine, because everyone trusts her to act like they would if they were all together. But what if she doesn't? What if her friends start being more careful not to disagree with her because of the absolute power she holds over their little space? What if the power that the software endows in her gets to her head?


The strange politics of our online tools amounts to an "implicit feudalism"—a rarely noticed nudge that inclines our interactions toward rigid hierarchy and draconian punishments, with no accountability through elections, due process, or term limits.


The feudal defaults emerged from the earliest online communities on bulletin-board services, which mimicked the permission-control systems in the innards of computer software. We accept our admins and mods as normal and expected, often without noticing how foreign those roles are for virtually any voluntary coming-together among people in other areas of life.


What if our online communities had the tools to practice a fuller range of self-organized possibilities?


We are part of a network called the Metagovernance Project, which is experimenting with building such tools. "Modular Politics" is a proposal we developed that outlines basic principles for online governance tools, such as:


  1. Modularity: Platform operators and community members should have the ability to construct systems by creating, importing, and arranging composable parts together as a coherent whole.
  2. Expressiveness: The governance layer should be able to implement as wide a range of processes as possible.
  3. Portability: Governance tools developed for one platform should be portable to another platform for reuse and adaptation.
  4. Interoperability: Governance systems operating on different platforms and protocols should have the ability to interact with each other, sharing data and influencing each other’s processes.


We decided to try implementing Modular Politics in a place where people are already meeting as peers, on their own terms: Minetest, an open-source, community-created, world-building game. It resembles the more popular, Microsoft-owned game Minecraft. Our Metagov colleague Seth Frey did a large study of Minecraft servers and found that autocracy is the norm; but would that still be the case if gamers had a different set of tools?


Translating the Modular Politics proposal into code has raised loads of questions that we never considered when it was all just in our heads and in words. We have had to appreciate more deeply than ever that software design is a political act. How we shape the inner workings and outer interactions will guide users' expectations and behavior. Engineering decisions shape the kinds of communities that users end up creating.


Modpol, as we call our implementation, is still very much a work in progress. (Come pitch in here!) But there are a few design decisions we have made so far that we're excited about—decisions that shift from the feudal defaults to defaults that are more consentful, even communal. Whatever you call them, these choices seem to better reflect how human beings in the wild actually behave together.


Groups, not roles. Rather than assigning particular powers to particular users, Modpol assigns powers to groups, which we call "orgs." Orgs can determine how to use those powers and how to make decisions about them, but ultimately it is on the level of group membership, not individual permissions, that things happen.


Consent, not oligarchy. The default decision-making process for orgs is consent of all members. This might sound utopian, but we believe it best resembles how groups of peers actually tend to interact, and it works so well most of the time that we don't even notice it. Ultimately, we hope to see a wide range of other governance "modules" that orgs can adopt, from clever voting schemes to juries and more. Users can decide to create an autocracy if they want, such as by delegating decisions to an org with only one member. But in Modpol autocracy is something that must be actively chosen by the members of an org—the "consent of the governed"—rather than being the presumption at the outset.


Inheritance, not blank slates. Most online platforms treat communities as parallel, indistinguishable software objects with no particular relationship to each other, each a blank slate upon its creation. Real social life, however, is infused with habit, tradition, and muscle-memory. Modpol attempts to reflect that. New orgs form within existing orgs, and they inherit the rules of their parents. Those rules can be changed. But the rules begin with whatever users were already doing before, so they can work with what they already know rather than starting from scratch.


Minetest is a game for building worlds. Really, it's an engine for many games, which players have developed and shared with each other. What nearly all Minetest games have in common is that they are places to build—block upon block. Players explore landscapes, gather resources, and use them to create the kinds of spaces they want to inhabit and show off.


Modpol is also meant for building. Players can create worlds of interlocking orgs, each with their own rules and processes. Modpol could be used to organize teams for Capture the Flag, or to govern an anarchist castle. It could enable experiments that explore the features and bugs of various ways of organizing and decision-making. Minetest is an engine for manipulating blocks in virtual space; Modpol is an engine for manipulating the flows of online politics.


Within orgs, users can choose the set of modules available to each other. In doing, they can craft their own rule-sets. They can create their own modules (for now, most are about a page-worth of code). Modules can call modules, which can call modules; what starts as simple can quickly become complex. Here is a snippet from our standard consent module, where it tallies up how many people have agreed to something:


    modpol.interactions.binary_poll_user(
        member,
        self.config.prompt,
        function (resp)
           self.org:remove_pending_action(self.id,member)
           if resp == "Yes" then
              self.data.votes = self.data.votes + 1
           end
           if self.data.votes >= self.config.votes_required then
              if self.data.result then
                 self.data.result() end
              self.org:wipe_pending_actions(self.id)
              self.org:delete_process(self.id)
           end
           modpol.interactions.org_dashboard(
              member, self.org.name)
        end
    )


The code is in Lua, the language Minetest understands. Lua was first developed in Brazil in the early 1990s as a lightweight language for embedding extensions into bigger programs. It is quirky and elegant, without the features and libraries it would need to run complex, modern programs on its own. In Portuguese, lua means "moon." Lua programs are orbiters, circling around other programs. They make no claim to be self-sufficient. This is fitting, because there is no point in governance tools without a world and a community worth co-governing.


We are constructing Modpol in orbits. There is spaceship modpol_core/, where most of the code lives, which can go anywhere in space but only works on the command line, just spitting out its lonely reports on its status in text:


-=< MODPOL DASHBOARD >=-
All orgs: (user orgs indicated by *)
[1] *Root
Pending actions in: 
All users: ntnsndr, medlab, luke


But when paired with the code in modpol_minetest/, Modpol has a map for planet Minetest.


Maps could be built for other Lua worlds—maybe Roblox, maybe Angry Birds, and lots more.

With this design, we hope that someday Modpol will travel to other worlds. But for now, we go on assembling this prototype. We're working with members of the Minetest community, who are skilled in the arts of commoning. Before leaving their orbit, we want to offer something of value to this particular species of world-builders, and learn together some lessons about the intergalactic possibilities in our minutest feats of community.


Download Modpol, and explore the code. Learn more about what we're up to at the Metagovernance Project and the Media Enterprise Design Lab at the University of Colorado Boulder. We can't wait to see what play this politics enables.


This article was written in collaboration with Luke Miller.


Also published on: https://www.colorado.edu/lab/medlab/2022/01/28/introducing-modpol-game-mod-governance