The Commons behaves like a network of sites: Humanities Commons, MLA Commons, MSU Commons, SAH Commons, ARLIS/NA Commons, HASTAC Commons, and about 3,000 WordPress sites operated by our users. All of these sites are in reality a single WordPress instance with a single filesystem and a single database. As I discussed previously in “A Federated Commons“, we are working to transform the Commons into a truly decentralized network. This will allow us to scale sustainably, tailoring each instance to the needs of its specific user base.
The glue that will make this future Commons a network rather than a set of loosely-associated independent sites is ActivityPub: the protocol used by Mastodon and an emerging world of decentralized social networks called “The Fediverse“. We originally saw ActivityPub primarily as a means of communicating between nodes and various services on own network, with the possibility of wider connections as a welcome bonus. Increasingly, however, we are seeing those wider connections as the most exciting promise of ActivityPub. We see ActivityPub as a central mechanism for transforming the academic web from a collection of siloed communities to an open and interconnected decentralized network where you can participate in discussions and access resources regardless of your position or discipline.
Connecting to the Commons
We have never sought to be the the social network for academics, but instead see ourselves as part of a network of platforms and websites with a common ethos of openness. Humanities Commons is based on the Commons-in-a-Box WordPress plugin developed by CUNY Academic Commons, and we have always sought to maintain friendly, consultative relations with them and other commonses.
Lately, we have been in discussions with other academic platforms about forming more substantial connections. For instance, we have discussed with Canadian HSS Commons how our repositories might share search results. And we are a member of the Michigan Digital Publishing Exchange (MDPx), which is looking for ways to share data and link workflows between digital publishing platforms and tools such as Manifold, Fulcrum, and Pilcrow.
Wouldn’t it be great if as a MSU Commons member you could follow someone on CUNY Commons or HSS Commons just like you can follow someone from MLA Commons or HASTAC Commons? Or have your Humanities Commons profile automatically updated to include a manuscript you just published on Manifold? We think it would be, and the way to do that is the same way that we plan to maintain connections on a federated Commons: through ActivityPub.
The promise of ActivityPub
One of the stumbling blocks we’ve encountered in our efforts so far to interoperate with other networks and services is coordination. If we are making bilateral or small-group agreements, then the first party to implement the communications mechanism will have nobody to communicate with; they will need to wait for another party to implement the mechanism on their side. And if one of the parties happens to change their plans or ceases to operate, then all of that effort is wasted. Further, each new relationship requires further negotiation and development effort.
What ActivityPub offers is a standardized way to communicate with any other platform that also implements ActivityPub—and there are lots of them! So our answer now to those who want to interoperate with Humanities Commons is don’t. Implement ActivityPub and interoperate with an entire ecosystem of open, decentralized networks and platforms, including (soon hopefully!) Humanities Commons.
How ActivityPub facilitates interoperability
As described by its specification, ActivityPub is a standardized protocol for sharing (short) content as activities on a decentralized network. What does that mean and how does it promise to facilitate interoperability for the Commons?
I have already discussed why standardization is important. Standardization is what allows for multiple parties to develop mechanisms for interaction without relying on any specific other party to do so. It is what allows us to say, “Don’t interoperate with Humanities Commons; interoperate with everyone!” ActivityPub is a standard of the World Wide Web Consortium (W3C). Established by Tim Berners-Lee, the inventor of the Word Wide Web, W3C is the main standards organization for the web. This means that we can trust that ActivityPub is here to stay, will have wide adoption, and is unlikely to be co-opted by special interests.
ActivityPub is a protocol. The internet is built on layers of protocols. Protocols are agreed upon processes that allow machines to communicate. Hypertext Transfer Protocol (HTTP) is perhaps the best known of these. It specifies how clients (web browsers) can request documents (web pages) from servers. It describes how browsers should make these requests and how servers can send responses. Other well-known internet protocols include Transmission Control Protocol (TCP), a lower-level protocol for transmitting data on the internet, and Internet Protocol (IP), a protocol for routing requests between servers on the internet.
The ActivityPub protocol specifies how users on a decentralized social network can communicate through posting to and reading from inboxes and outboxes. You can send messages by posting to another user’s inbox. You can read what a user is posting by reading from their outbox (this is like viewing someone’s timeline on Twitter or Instagram), or by requesting to follow them, which will result in their messages being delivered to your inbox. Using this mechanism, users can follow and correspond with any other users as long as they have inboxes and outboxes that conform to the ActivityPub protocol.
As the inbox / outbox terminology suggests, ActivityPub shares many similarities with email. Just like email, the content of messages is delivered from creator to recipients in the message body. This content is then stored on the server of each recipient, as it is for email. And again just like email, only you can access the contents of your inbox. Others can send to your inbox, but only you can read from it.
ActivityPub is a protocol specifically for sharing short content as activities. If you think about social networks like Facebook, Twitter / X, Mastodon, Instagram, and many others, they are all variations on a common theme: users posting short pieces of content that are consumed by followers. Those followers view content on a timeline that combines streams of content from many sources into one personalized view. Followers can respond to and re-share that content. On the Commons, this content could be status updates, blog posts, uploads to our repository, or forum posts within a group.
You cannot follow someone on Instagram from your Twitter account. They have similar basic structures, but no common protocol that would allow them to communicate. This is what ActivityPub does: provide a common, standardized protocol for sharing this type of content on a decentralized network. This means that there is no central authority or storage location for these activities. Social networking sites like Facebook or Twitter have long had the ability to embed their content elsewhere and even interact with it from elsewhere. You can (or could until recently) embed a feed of Tweets in an external website. But that content remained on Twitter’s server. Same for embedding Instagram posts or Facebook discussions. ActivityPub requires no such central site. Rather, content is shared between sites, so that you can follow someone on BookWyrm from hcommons.social, or someone on scholar.social from physics.social—or any other site implementing ActivityPub.
Challenges of ActivityPub
As anyone who has joined hcommons.social or another Mastodon instance is surely aware, ActivityPub and the Fediverse are not without challenges. For us, one acute issue is the fragmentation of identities across multiple accounts. On hcommons.social I am @mikethicke@hcommons.social but on the social reading site BookWyrm, I am @mikethicke@bookwyrm.social. If I had a WordPress blog with the ActivityPub plugin, I would have yet another identity. There is no built-in mechanism for automatically relaying posts from one account to another, so if you want to follow my reviews on BookWyrm or my posts on WordPress, you need to follow those specific accounts, or count on me boosting them from my hcommons.social account.
This problem is acute for the Commons because this will also apply to my identities on HASTAC Commons and Humanities Commons when we decentralize. Currently, if someone follows me on any site within the Commons network, they follow me on all of them. This is due to the single-instance nature of the site. But when we decentralize, someone who follows my HASTAC Commons account will not see updates from my Humanities Commons account. This is a problem for us, as we don’t want our structural decentralization to result in a fragmentation of our user base into siloed organizations; that goes exactly against our mission. Our planned solution for this is to have a mechanism for combining your various ActivityPub streams into a single stream centered on your Commons profile. There are some potential pitfalls here (we don’t want to inundate your followers with autogenerated spam, for example), so we will have to be careful about how we implement this and about giving users ultimate control over what goes into their feed. Nevertheless, we think this could be a really valuable service for Commons users as the Fediverse and our network expands.
Relatedly, the fragmentation of identities across the Fediverse results in a fragmentation of profiles. ActivityPub is a protocol for sharing activities—status updates, discussion posts, book reviews, publications, and so on. But one of our most important and best-used features is the Commons profile: a central location for your academic identity. ActivityPub includes a notion of actors who create activities, but there is no standardized way of sharing data about actors beyond their name and URL. For the Commons network to remain cohesive, we need a way to synchronize between a person’s various profiles so that when you update one, your others are automatically updated correspondingly. Our original plan for this, as depicted below, was to have a “Profile and Permissions Sync” centralized service that would coordinate between your various identities.
I no longer believe this is the best approach. It would work, but it runs into the same problem with connection I discussed above: to synchronize profile data with the Commons, you would have to develop a mechanism for synchronizing with us specifically. What would be better would be a standardized mechanism for synchronizing profile data in general. There are some attempts at this, such as h-cards, OpenID, and, for academia, ORCID, but I’m not sure any of these meet our exact requirements.
Conclusion
ActivityPub is the protocol that will allow the Commons network to decentralize and scale sustainably. It is also the protocol that will allow us to interoperate with other knowledge communities and applications. While it has some challenges specific to our needs, we are very excited about its potential and the opportunities it presents for the academic world as a whole.
In a future post I plan to do a deep dive on profiles. Until then, thank you for reading! Any and all feedback is welcome, either as comments here or on hcommons.social, our Mastodon server.