How to Make the Fediverse Your Own

Welcome to the fediverse! The fediverse is a network of social spaces that we the users can govern for ourselves. This is a guide to help you do that—because the technology won't do it for you. This is a love letter from your friends at Social.coop, which has been running (and enjoying!) a democratically governed social media space with Mastodon since 2017.

As many people are coming to the fediverse from birdsite (that's what we call Twitter), it's important that we be intentional. A Mastodon server is just a tool, not a solution. There are lots of other fediverse tools out there as well. But what matters above all is how we use that tool, and how we co-govern it. If everyone just all joins the same server, we will probably end up with something worse than Twitter. Lots of servers, also, are run by admins who do not necessarily have accountability to their users. For the move to the fediverse to truly be a step toward better social media, we need to be intentional about how we organize ourselves with it.

In what follows, we share some practices based on our experience, which we hope might be useful for your community. But we're "just sharing"! We are excited to learn from what you end up doing differently.

TLDR: A democratic fediverse involves intentionally setting up democratic governance, democratic economics, and democratic community. It's fun!

🤝 Form a commons

Before you start tooting, it's really important to lay the foundation of a commons. A commons is a combination of practices, culture, and relationships around common resources. To govern technology democratically, a community should have a commons in place first.

Here are some basic components of a commons:

A purpose. What or who is your community for? Does the community exist already, or does it have to be cultivated?

What we do: We defined our purpose early on in two ways. First, Social.coop is an experiment in user-governed social media; it arose out of the buytwitter.org campaign, which made a shareholder proposal at the company calling for user ownership and governance. Second, Social.coop is a community hub for people who identify with the cooperative movement—particularly with bringing that movement into tech.

A legal entity. If some big tech company doesn't own your community, something else needs to. Ideally, individual founders should not be personally liable for what happens on it. A great solution is to be fiscally sponsored through an Open Collective fiscal host. You could also create your own entity—a nonprofit, a co-op, or an LLC—though that is more complex. One way or another, you'll want to have an explicit stewardship design.

What we do: Social.coop started out by being fiscally sponsored by the Open Source Collective on Open Collective. In solidarity with the co-op movement, we switched to Platform 6 Co-op, a UK cooperative. though we still use Open Collective's platform to facilitate that. This means that we are officially a cooperative, although we are also a virtual co-op, in the sense that the members of Social.coop are not actually the legal members of Platform 6. Social.coop members, however, have governance rights in our community, as defined in our bylaws.

A place to collect and manage funds. A shared space requires some shared economy. If one person or a small group runs the space out of their resources, they will be the ones in control, in the end. To prevent that, make sure there is a way for the community to co-fund the space.

What we do: We use Open Collective to manage our funds. Members can sign up there to make regular contributions, on a sliding scale based on what they want to pay. We also manage expenses and payments on Open Collective, so all our financial activity is transparent, not only to our members but to the world. Open Collective connects directly with our fiscal host, Platform 6, so it makes hosting us easier for them.

Bylaws. Next, make explicit how power flows in the space. If you don't do this, you will likely wind up with a "tyranny of structurelessness." Explain here who gets to make decisions, who holds authority, and how the members can keep them in check. This document doesn't have to be very long or legalistic, at least at first, but be sure to start with something that enables you to a) make some basic rules in a clear way and b) change the rules (and bylaws!) as the community develops. If it helps, you can use CommunityRule.info, a simple Web app for making rule-sets in an intuitive way.

What we do: We keep our bylaws on our wiki. They are pretty similar to how they started, but we have made some revisions over time, largely to clarify things that were ambiguous.

A method for deliberation and decision-making. You'll need some way to make decisions in digital space. This will work in tandem with your bylaws, which should clarify what needs to happen for a decision to be made. You could use your fediverse instance itself, if that works, or else another space that is comfortable for your community.

What we do: We use Loomio, a platform developed by a worker co-op, to discuss and carry out Social.coop governance. Loomio has lots of really helpful tools for polling and decision-making, and it enables more focused conversation than Mastodon does. But the downside is that it requires people to have a separate account, and it can be a bit bewildering to use. Pro tip: Loomio's daily digest feature is a great way to cut down on email notifications while still getting them.

A code of conduct. To set expectations about how people can feel welcome and comfortable in your space, establish an explicit code of conduct. This is super important, as Coraline Ada Ehmke explains. Like your bylaws, your CoC can evolve over time. To start out, just begin by copying an established one out there, like Ehmke's Contributor Covenant.

What we do: We keep our code of conduct on our wiki. It is adapted our CoC from the Citizen Code of Conduct according to the specific values of our community and the use-case of social media. We haven't modified it since 2017, but it is probably due for some improvement. When we first started, we actually didn't have a CoC, and that caused some painful early conflicts for us. Don't make that mistake!

🖥️ Set up some tech

To join the fediverse, you'll need some technology. There are a few different approaches to doing this, and all of them still require some degree of familiarity with things like Web servers. Ideally, your community should make a point of ensuring that members with technical skills can share those skills with others who want to learn them. The DiscoTech framework might be useful in guiding that skill-sharing.

Here is some info about setting up a server from Mastodon HQ. Another approach is to use Cloudron, a platform that manages multi-app clouds with integrated account systems. It automatically manages software updates, which can otherwise be a big headache. And it allows you to pair Mastodon with other services. Either at the beginning or over time, your community might want to use more than just Mastodon, because Mastodon alone doesn't offer a lot of resources for self-governance.

What we do: Social.coop's Mastodon server is hosted with Hetzner, a German hosting company that uses renewable energy to power its systems. In addition to Mastodon, we also host a wiki system. Our code is hosted at git.coop, a cooperative GitLab instance. We also discuss technical issues in a Matrix room, which is less noisy than Social.coop itself. Our domain name is managed by the International Co-operative Alliance, like all .coop domains, though we purchase access through Gandi.net, an ethical registrar.

A matter of ongoing debate for us is how much we want to expand our range of services. Each platform requires additional maintenance, labor, and expertise. Yet as our community matures, people want to bring more of their Social.coop-related activity under our own control. Community control is kind of addictive!

One solution we've found to this dilemma is to partner with other co-ops. For instance, Social.coop is a member of Meet.coop, which provides videoconferencing service using Big Blue Button. Any of our members can use this, and we use it for our official meetings. Rather than operating our own GitLab server, also, we use git.coop, maintained by Web Architects, a worker co-op. This way, we can expand our services without additional tech burdens, while advancing our mission of supporting the co-op movement.

More important than setting up a server, however, is maintaining it. (When you set it up, nobody is relying on it yet!) For that, read about our Tech Working Group below.

💃 Cultivate community

User on-boarding

Be intentional about how people join. Is your instance open to anyone? If so, why? If it is more gated, what kinds of friction do you want to introduce to the process? Friction can be your friend! The balance between friction and accessibility will be different from community to community—take the time to consider what balance is right for yours.

What we do: Social.coop registration is not automatic, but we are always welcoming new members through a registration form. The purpose of this is to ensure that people who join meet two criteria: they must have an account on Open Collective, so they can contribute to Social.Coop, and they must agree to the code of conduct. We also ask them to articulate why they want to join, to avoid registration spam. This isn't foolproof, for sure, but it has generally worked to ensure that our membership has shared values and purpose. We have a team that manually reviews applications and manually on-boards new members. Sometimes applicants have gotten lost in this process because of issues with spam filters, and improving it is something we have talked a lot about. We might have more friction than we need. Now that we have members coming in in large numbers we may want to think about whether we want to limit Social.coop to people who share a few interests (co-ops, floss, social justice...) or keep it open to anyone who agrees with our code of conduct. Another question is whether we are looking for members to be more like members of a worker co-op, where the members should have shared values and vision, and strong trust, or members of a credit union, where it is not essential for them to share values and vision.

Implementing a code of conduct

Moderation is hard work, and it can be damaging to the people doing—whether because of being exposed to the worst content, or because of the tensions that arise in conflict. Moderators can easily burn out. But moderating can also be a rewarding, important role to play.

Take all this into account. Make sure that people doing moderation work have some training and support. Ensure that the role rotates, so people are less likely to burn out.

What we do: Our elected Ops Team handles moderation through a rotating "on call" moderator role, who addresses any issues that arise in one-week shifts. This ensures that moderators are approved by the community and that no one person is moderating more than every few weeks. There is a Reporting Guide on how to report code of conduct violations.

Diplomacy with the fediverse

In the fediverse, moderation isn't just about particular users; it also involves moderating entire servers. For instance, if a particular server harbors hate speech and other abusive content, your server might want to restrict the content from it. Other servers might be closely aligned with yours, and you might want to encourage interaction with users there. In this way, your community can collectively determine its relationships with the rest of the fediverse.

What we do: Social.coop has a list of servers that we we do not "federate" with. "On call" moderators are responsible for fielding requests to defederate servers that violate our Federation Abuse Policies.

🧑‍🔧 Share work and power

If a fediverse server is controlled by just one person or a small group, everyone else is at their mercy. They could turn off the server and everyone would lose service and data. They will have outsized power over the community. But when work and power are widely shared, the community can be much more resilient and healthy. When we share the costs, we ensure that the community has the resources it needs.

According to an informal Pol.is poll (participate), the items with the most consensus (as of Nov 12, 2022) in response to the prompt "How to tell if a Fediverse instance is run/managed by its users?" were:

• members can participate in selection of mods
• members can see and give feedback on budget
• members can see and give feedback on stuff admins / mods do

And more. Beyond just choosing and providing feedback to those in power, community members should be able to actually participate in operations. Form operational teams to carry out specific activities for the community, and rotate members among them, so operational skills become distributed widely.

What we do: The two main ways we share work and power are

• Collective decision-making on important decisions, largely in Loomio
• Opportunities for participation in operational committees

Social.coop has three major committees, described here:

• Community Working Group - The CWG is responsible for the well-being of the humans! Its members meet each month and receive a stipend for their work. The committee manages registrations and onboarding, as well as moderation and conflict resolution on Social.coop. It also helps facilitate governance processes on Loomio and coordinates with other working groups. It organizes strategy sessions, encourages reading groups, holds community cafe events, and enables other types of community-building events. Finally, it maintains the code of conduct and other guidelines.
• Finance Working Group - Its members' job is to keep an eye on the money. The FWG has admin access on Open Collective and approves all expenses that are submitted there. They also review the balance sheet regularly to check on how things are going, and report to the larger community. The FWG is currently an all-volunteer position to avoid any conflicts of interest. It uses the Gateway software so that approvals on Loomio automatically release funds on Open Collective.
• Tech Working Group - The tech operations team are those members who do the work of development and maintenance of this IT infrastructure. Much of the management of that is done on a GitLab project space we use courtesy of Web Architects, here.

🛸 Imagine the future

Nothing is perfect! Here are some ideas for things we might want to do in the future, and that would make our work easier.

Tighter integration among the tools we use. Currently, because of our democratic governance, we rely on multiple services, each with its own account system, just to run our single Mastodon instance. That shouldn't be necessary. Ideally, users should need only one login to access all related services. Fewer services should also be necessary. Perhaps we could perform more of our governance activities, such as payments and decision-making, on Mastodon itself. Or perhaps it is enough to simply have one login for all the services through a "single sign-on" system. We're excited about the Bonfire project, which uses a modular approach so users can pick and choose various apps integrated on their server.

Simpler hosting. Currently the fediverse requires that every instance have people with some technical expertise involved. That can really reduce accessibility for communities that lack technical privilege. In the future, we hope that communities should be able to form instances that they can fully control but that do not require them to perform technical maintenance. Ideally, this would happen through cooperatives that are accountable to the communities they support.

Credits

This document was drafted during the influx of interest in Mastodon after Elon Musk acquired Twitter in 2022.

• @literally
• @matt_noyes
• @ntnsndr