Hi GFTW community! I’m Josh, one of the founders of the Metagovernance Project. We’re building a software toolkit, Metagov, that helps online communities build their own digital governance systems. Using Metagov and its various supported services, communities can spin up democracies, governance boards, reputation systems, juries, and even full-fledged economies (featuring Web Monetization!) with the click of a few buttons.
A caveat: Metagov is a “governance layer” for interoperating and orchestrating a whole bunch of other governance apps and services. It doesn’t work without those apps. That’s why we’re starting by integrating projects like Loomio, SourceCred, and Open Collective as Metagov modules alongside in-house modules like PolicyKit, CommunityRule, and Govbase, in order to pilot this experiment.
Here, we wanted to report on the results of our work over the past 6 months and some further planned experiments with our Web Monetization plugin.
Progress on objectives
There were three mains goals outlined in the initial proposal:
- To build a prototype that suits the needs of at least two of our diverse platform partners, creating the groundwork for what we hope will become a universal governance standard.
- To experiment with users in the wild and better understand how to further hone the core logic of modular governance systems.
- To better understand the monetization opportunities for the Metagovernance Project itself.
We’ve completed the first and third goals (see the next sections), and are still in the middle of completing the second goal (see “What’s next”).
Current implementation
The Metagov community currently uses Probabilistic Revenue Sharing to share revenue generated on the community’s Discourse server. Each time a web monetized visitor loads the page, a payment pointer is selected from a list of predefined payment pointers.The visitor pays to the chosen pointer until the page is reloaded or closed.
The revshare config is governed by Metagov via PolicyKit, a governance “driver” that ships with Metagov. We have a policy in PolicyKit that initiates a vote each time somebody requests to be added to the revshare config. That policy itself is governable by PolicyKit constitution policies. So, depending on the PolicyKit configuration, certain community members can propose changes to that policy, in order to change the way the RevShare config is governed.
Tools Used
- PolicyKit
- Metagov
- Discourse Plugin: discourse.poll, discourse.create-message
- RevShare Plugin: revshare.add-pointer, revshare.pick-pointer
- Discourse plugin: discourse-web-monetization
Required Setup for this Use Case
- A community exists in PolicyKit, and it has the Discourse Plugin enabled for Metagov.
- The discourse-web-monetization plugin is installed on the Discourse server.
- The plugin is enabled and configured in the Discourse admin panel.
There is a custom user field called “wallet” that was created by a Discourse admin. Users can input their payment pointer on the user profile page:
This Policy exists in PolicyKit for the community.
Voting on RevShare changes
This is what the PolicyKit Policy looks like in action:
- Alice adds the payment pointer “$alice.wallet” to her profile page
The Metagov bot creates a Discourse poll for people to vote on whether or not the wallet to be added. The conditions of the vote (who is allowed to vote, what the closing conditions are, what the text says, etc) is all determined in the PolicyKit policy. This enables the community to propose changes to it. With this community, each wallet always has an equal weight. That’s also defined in the policy, so the community can control it.
The Metagov bot sends a message to Alice to notify her that the vote is underway.
-
The PolicyKit policy decides when the closing condition of the vote has passed. Either 24h passed, OR there was at least 1 approval from a user with Trust Level 3, OR there was at least 1 disapproval from a user with TL3, OR at least 5 people voted in total.
- The PolicyKit policy determines whether the vote PASSED or FAILED.
- If it passed, the user's payment is added to the revshare config. They will immediately start receiving revenue from visitors to the Discourse. Alice is notified.
- If it failed, the revshare config remains the same. Alice is notified.
Key activities
We recently had a technical workshop in NYC that focused on the architecture of Metagov itself and the relationship between Metagov and its integrated services (e.g. modules like PolicyKit, SourceCred, Open Collective, Agreement Engine, and Web Monetization). The goal of these discussions was to understand how we can re-design Metagov in order to optimize the experience of the developers that actually use Metagov. One question that arose in these conversations: are the actual “customers” of Metagov the communities implementing governance systems or the partner services that we integrate with? A lot of our current work has been driven by the needs of these services, e.g. PolicyKit, SourceCred, and Web Monetization all need integrators in order to function across platforms. Metagov is designed to be a backend service, and if it’s working well, the end-user should never need to know that it exists.
However, we also identified some major cross-service needs. For example, authoring policies that work across multiple Metagov services requires some level of identity merging / entity resolution across these services. Another requirement: monitoring, logging, and oversight of the multiple services that a community uses. Should Metagov itself be providing these functionalities, or should we integrate separate services for identity and for monitoring? And if we’re doing it ourselves, we will likely need some sort of front-facing UI so that community admins have a workflow to perform identity merging and to monitor their services. We have yet to resolve this tension.
But in the meantime, we’ve produced a draft “standard voting API” that integrates a number of different voting services, so that developers can build applications and plugins on top of a generic API rather than committing to a single voting service. (This also fulfills one of the key deliverables described in our original proposal, “an interoperable standard”.) One of our next steps is to convert the “voting on RevShare” policy described above to use this standard, so that the voting which currently occurs through Discourse Polls can happen on any other supported platform (e.g. Pol.is, Loomio, or Snapshot).
Communications and marketing
We hosted a hackathon! Over 100 hackers and developers participated in our Open Web Governance Challenge, co-hosted by NEAR, with over $25,000 given out in prizes and awards. The Metagov Slack community also continues to grow organically through our weekly seminars.
We’re planning a public release in late November, once we have time to evaluate and iterate based on our initial partner use-cases.
What community support would benefit your project?
We’ll be developing standards for identity & multi-platform communities over the course of the next quarter, and we would love to hear from the Web Monetization community about how standards could support the work that you folks are interested in.
Stay in touch through our email list (just send a message to hello@metagov.org) and let us know if you know of a community or a platform that is thinking about governance. We’re always looking for beta testers!
What’s next?
The main priorities for us in the near future are (1) to continue working on our initial partner use-cases and (2) to conduct more user interviews so we can make decisions about our architecture.
We also discussed a potential collaboration with PeerKat, another GFTW Grantee, on using Metagov for their own implementation of probabilistic revshare. However, since they are working in a smart contract, we first need to build a blockchain plugin / oracle for Metagov, which is nontrivial. Still, it's a really interesting idea and one we hope to get to at some point as we grow.
Some more concrete features on our priority list:
- Add a UI component that displays the community’s revshare configuration transparently, and all historical changes to it. This UI could be in Discourse as part of the plugin, or in PolicyKit as a special RevShare view.
- Support context-aware payment pointer selection. For example, if the monetizer visitor is viewing a topic authored by thelastjosh, dynamically get a payment pointer but give 50% of the revenue share config to thelastjosh, and the remaining half to the rest of the community.
- Another example: support a configuration where revenue is split equally among the topic author and the topic participants.
- Another example: support a configuration where revenue generated from topics tagged “dev” are distributed among the core dev team, and revenue generated from topics tagged “support” are distributed among the support team.
- A Coil wallet integrator so that different Metagov modules and policies can directly govern wallet interactions.
Top comments (0)