Twitter’s recent troubles have catalyzed unprecedented attention on Mastodon as an alternative. In turn, this has introduced many to the Fediverse—a loose collection of services that, like Mastdodon, use the ActivityPub protocol to communicate with each other.
At Humanities Commons, we have long considered ActivityPub to be the most promising way to expand from our current, single-site, structure to a network of associated Commonses. We have taken Mastodon as an inspiration and model for a new, federated Commons network.
I hope to use this blog both to keep users at Humanities Commons informed of our plans and progress toward this goal of a renewed Commons and Commons network, but to also have conversations with all of you about our direction, about how we can best serve your needs, and about how you can contribute to our journey.
In this post, I want to describe in general terms how the Commons functions as a pseudo-network now, some of the challenges we’ve experienced with that structure, and how a federated or decentralized Commons might address those problems. In future posts I will go into more detail about how different components of the site—such as profiles, groups, sites, and the repository—might function in a federated Commons, as well as discussions of how we plan to implement all of this.
Where we are now
Many users of Humanities Commons may not realize that it functions as part of a network that includes several other Commonses: MLA Commons, MSU Commons, ARLIS/NA Commons, UP Commons, SAH Commons, and HASTAC Commons. Membership in these other Commonses is generally tied to membership in an associated society or institution, such as the Modern Language Association for MLA Commons or Michigan State University for MSU Commons. In the current model, members of a particular organization interact with each other on their home Commons, and interact with the wider community on Humanities Commons.
Although the current structure functions in many ways like a network, it is run off of a single WordPress installation with a single database and single set of users. Access to a particular Commons is controlled by the WordPress user permissions system and various customizations we have made to coordinate with other organizations.
This system has advantages—it makes it easy to add a user to another organization, and it means that a user’s profile on HASTAC Commons is automatically the same as on UP Commons, as both profiles are querying the same data. From an administration perspective, it means that we only need to run updates once, and we have a central place from which to administer all of our users and sites. However, it has led to increasing issues as the Commons has grown, and we don’t believe it is a sustainable structure for future growth.
One of the biggest technical challenges we have encountered is that as more organizations join the Commons, each with slightly different needs than the others, the complexity of the site has increased beyond our ability to manage. As every organization shares the same site, and every new functionality potentially interacts with every existing one, new development almost inevitably causes unexpected problems with existing functionality.
An organizational challenge we face is that a centralized, single-site structure implies centralized administration and support. Our small team is responsible for supporting and maintaining the entire site, and as the Commons grows this becomes more and more onerous.
How a federated Commons could be structured
For a federated, decentralized Commons, we would split the current, single single instance structure into multiple instances. From a user perspective, interacting with fellow members of a particular instance would work much the same way as it does now. However, interactions with users on other instances would be mediated through the ActivityPub protocol. Rather than visiting Humanities Commons to interact with users beyond your home Commons, you would find, follow, and message them all from your home instance. You could find, join, and contribute to public groups in other Commonses from within your home. The only exceptions would be viewing external blogs and interacting with the repository, which will be a separate, centralized application.
The glue holding these instances together—making them a network rather than a collection—is the ActivityPub protocol.
As implied by its name, ActivityPub is a protocol for publishing activities. These activities are messages, or posts, or notifications. They can be directed at particular receivers or at anyone who has followed you. In the Commons context, these activities could include making a deposit to a repository, updating your profile, posting a status update, replying to a group thread, or sending a private message to another user. Nearly all of the activities you perform on the Commons now can be captured as activities than could be transmitted between nodes on a Commons network through the ActivityPub protocol.
Additionally, by implementing the ActivityPub protocol as our method of communicating between instances and users, we would also be able to interact between other services on the Fediverse. In particular, your Mastodon account could be your MSU Commons account, and your Mastodon profile could be your MSU Commons profile. Not synced to but identical to. You could participate in Commons group discussions using a Mastodon client, or any other ActivityPub-compatible client.
The benefits of a decentralized, federated structure
This structure would allow individual instances on the Commons network to be operated entirely independently, so that an institution or group could launch their own Commons, with or without our assistance, and join the network. What customizations were made to an instance would be up to its users and administrators. This would make managing the network much more sustainable for us, and we think also make other organizations more confident in joining the network. We are still exploring and discussing the range of services and support we could offer in such a network, but there will always be at least one Commons operated by our team.
Splitting the Commons into separate instances each with only the functionality required for their needs would reduce the number of possible interactions and make the whole easier to manage. It would also let each Commons make its own decisions about the tradeoffs between functionality and maintainability without negatively impacting the others.
Besides making support and maintenance more sustainable, a decentralized system would allow us to scale the network’s infrastructure in a more targeted and robust way. Smaller instances would require less powerful servers and smaller databases, while very large instances might require complex load balancing and multiple powerful servers. One instance experiencing lag due to heavy traffic would not slow others on the network.
Conclusion
This has been a brief, and speculative, discussion of where we see the Commons heading in the future. In future posts I will go into more detail about how different parts of the Commons might operate in a federated structure, and how we’re thinking about implementing all of this.
I would also love to hear from you about how you imagine the Commons operating as part of the Fediverse, or in what other directions you would like to see the Commons develop.
Finally, if you would like to be involved in this next phase of the Commons more substantially, please get in touch! I would be excited to talk about how you could might contribute.