Metagov as software bundle

Metagov Gateway
#1

This use-case describes a platform or online community using Metagov as a software bundle: namely, an easy way of installing and configuring a bunch of related software services, akin to cPanel for domains, Wordpress for websites, or Anaconda for data science. More verbosely:

a software bundle of a number of existing governance libraries, tools, and services […] that can be installed, deployed, and configured on at least two platforms such as Slack, Discord, Matrix, Mastodon, Discourse, or dada.nyc

For background, refer to the discussion on GitHub: META-ISSUE: Metagov Prototype enhancements · Issue #21 · metagov/metagov-prototype · GitHub

User flow:

  1. A server host / platform operator, installs Metagov on a server, e.g. Discourse
  2. A server host or other person with administrative access to the Metagov instance creates a Metagov community using the Metagov instance (possibly in the same install process as #1)
  3. Metagov automatically creates a PolicyKit instance for that community
  4. Metagov automatically creates a Kybern instance for that community
  5. Metagov automatically creates a SourceCred instance for that community
  6. Metagov automatically creates an Open Collective instance for that community
  7. Metagov automatically creates a Loomio instance (i.e. a Loomio community) for that community
  8. Some instances are automatically enabled (e.g. PolicyKit), while others are “inactive”
  9. Community administrators can activate or de-activate instances as needed.
#2

My understanding is that Metagov would need to create those communities “as metagov” - that is, through a MetagovBot account, which would be different for each MetaGov installation. I favor this approach, since it allows Metagov to strictly control the governance on those sites. However, for some platforms there may be limits to how many communities that server’s version of MetagovBot can own. So this solution may not scale. I would say that if we want to automatically create communities on other platforms, we should limit ourselves to doing so for platforms that don’t have ownership limits.

I suppose theoretically we could task MetaGov with the responsibility for:

  • knowing how many communities each platform lets a single user own
  • tracking how many communities they current have owned by their bot
  • when they’re close to running out, automatically creating an additional bot to use and/or pinging the metagov admin to make an additional one
1 Like
#3

A “bot” approach sounds right to me.

#4

@Shauna so you’re saying for example there is a single OpenCollective MetagovBot user for a single Metagov instance (say prototype.metagov.org), and it is an OC admin on all OC collectives that are hooked up to that metagov instance?

This feels like way too much access for a single API key–– the (bot) user that has access to all of these collectives that are completely unrelated. If that user’s API key is compromised, it affects all the collectives. Is it worth it, just for the auto-create-collective feature? We could also chat with OC about this to see what they think. It should also be noted the OC doesn’t actually support bot accounts, the MetagovBot account is a user account that is tied to my email address.

I also don’t think we can generalize this across platforms. The idea of “Metagov automatically creates a____ instance for that community” is very different depending on the platform. Take Loomio as a counter-example to OC: in Loomio you access the API using an API key that is tied to a specific community––NOT a user––so we couldn’t have “one-api-key-to-rule-all-communities” even if that’s what we wanted.

My general feeling is that it’s safer to have one “bot” (API key, or bot user) per instance+community+platform instead of per instance+platform, even if it’s more work for the community admins to set up. But I think we should be talking about this on a platform-by-platform basis, not generalizing it.

#5

I didn’t think about the security tradeoff there. In my proposal, there’d be very few opportunities for the API key to be compromised, since it’s not user-facing at all, but that doesn’t mean it can’t happen - and if it did, we’d potentially compromise all communities on that third party platform associated with the particular metagov install.