No Description

SkylarHew da7b996a8b Added ldoc comments for all lua modules and generated docs in documentation index.html 2 years ago
documentation da7b996a8b Added ldoc comments for all lua modules and generated docs in documentation index.html 2 years ago
lib 645cc6f690 Changed Minetest module listing to remove slugs, retain only names 2 years ago
modpol_core da7b996a8b Added ldoc comments for all lua modules and generated docs in documentation index.html 2 years ago
modpol_minetest da7b996a8b Added ldoc comments for all lua modules and generated docs in documentation index.html 2 years ago
.gitignore beeaa626a9 updated list_users functions to reflect new instance naming standard 3 years ago
GOVERNANCE.md b9d2b73611 Correction: files added 2 years ago
LICENSE 4411c01ebb Corrected copyright statement on LICENSE 2 years ago
README.md db57313165 Update README.md with some additional details about changing modules 2 years ago
depends.txt b80f025093 Removed "default" from Minetest dependency list, thanks to @gbrrudmin 3 years ago
description.txt 51d5e404e9 Tweak to description.txt 2 years ago
init.lua 3e3f737915 A little more cleaning up 2 years ago
login.lua cfef9b29b0 Bugfixes on CLI interactions 2 years ago
mod.conf 1e81b830c4 Fix on the mod.conf before submission to ContentDB 2 years ago

README.md

Modpol for Minetest

Modpol, short for "modular politics," is an extension that enables diverse governance processes on multi-user platforms. It offers a library that enables users to create or adapt their own modules that add specific governance functionalities.

This implementation is a mod for Minetest, a free/open-source voxel game. It is designed to be easily adapted to other multi-user platforms that also employ Lua as an extension language.

How to use it

Modpol is built around groups called orgs. At the base is an org with all users in it, called Root by default.

Modules enable people to do things within orgs, such as decide on membership, grant powers to the org, and much more. Modules can be added and modified by users to meet their needs. Modules can also be nested in each other, so one module can rely on another module to accomplish a process. Within an org, choose the module that you want to use:

Modules might simply carry out actions in the game, or they might require a group decision to do so. They might also change the modules available to users of a given org. There are currently two ways of doing this:

  • Remove modules from the list of modules loaded in modpol_core/api.lua and modpol_minetest/api.lua. This will make those modules no longer available to any user.
  • Remove modules for a given org from within the program using the Change modules module. The removed modules can be re-added in any org by using Change modules again.

The point is that Modpol should give you the ability to do whatever kind of politics you want with your modules. If there is something you would like to do that is not available, develop a module for it (or ask us for help!).

Installation in Minetest

To use this in Minetest, simply install it in your mods/ or worldmods/ folder. Minetest will load init.lua.

In the game, open the Modpol dashboard with the command /mp.

For testing purposes, players with the privs privilege (generally admins) can use the /mp command, which resets all the orgs and opens a dashboard.

Standalone Version on the Command Line

Modpol can also be used independently of Minetest as a command-line tool. Currently command-line use of modpol requires a Unix-style system, but it is intended to become more fully platform independent.

The command-line version is in the modpol subdirectory. To run the program on Unix systems in CLI mode, install lua or luajit and execute the following in this directory:

$ lua[jit] login.lua

You can also interact with the interpreter by starting it this way:

$ lua[jit]
> dofile("login.lua")

In the interpreter, for a list of global functions and tables, use modpol.menu().

Storage

By default, a data directory named "data" will be created in this directory. /data will contain a log file and serialized program data files.

Another storage method may be chosen in modpol.lua. A StorageRef-based method for Minetest 5.* is included: storage-mod_storage.lua.

Design philosophy

Modpol seeks to implement a theoretical framework, also called "modular politics," which proposes these design goals:

  • 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.
  • Expressiveness: The governance layer should be able to implement as wide a range of processes as possible.
  • Portability: Governance tools developed for one platform should be portable to another platform for reuse and adaptation.
  • 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.

Additionally, Modpol seeks to counteract the tendency for "implicit feudalism," according to which rigid, top-down power structures are the norm in online spaces. To this end, some design patterns include:

  • Groups, not roles: While most platforms assign powers through particular permissions given to individuals, in Modpol, power lies in groups (which Modpol calls "orgs").
  • Consent, not oligarchy: Rather than assuming that decisions will be made by a few power-holders, the software assumes that consent by all affected users is the norm.
  • Inheritance, not blank slates: When a new group is formed, it inherits the patterns of what preceded it, rather than imagining that it is starting from scratch.

It is certainly possible to use Modpol to replicate practices of implicit feudalism, such as all-powerful admins, but doing so requires extra work to overcome these defaults.

Credits

This project is led by Nathan Schneider of the Media Enterprise Design Lab at the University of Colorado Boulder, as part of the Metagovernance Project.

Contributors include:

  • Luke Miller (co-leadership, main control flow, object orientation, module spec)
  • MisterE (early project refactoring, core feature development)
  • Robert Kiraly OldCoder
  • Skylar Hew (documentation)

We are grateful for initial support for this project from a residency with The Bentway Conservancy. Read about us in The Field Guide to Digital and/as Public Space.

Contributing

We'd love to welcome more contributors. Please join the conversation in the Issues, our Matrix.org channel, and the Minetest.net forum.

Learn more about the project and how to develop your own modules in the wiki.

Licenses