Sunday Readings: some historical context
Welcome to another episode of the bi-weekly Sunday Readings. Last time I placed the rise of the fediverse in a larger context, with some reflections on the state of the internet at large. This time, I want to zoom in a bit more on the context of how the technical side, the ActivityPub protocol, came to be.
If you’re a bit unsure what ActivityPub is: think about it as the commonly agreed shared technical language that helps that we can all communicate on the fediverse, even if we use very different software. ActivityPub makes sure that you log in on Mastodon, and see posts that are made on PeerTube.
While a large group of people might have only started hearing about Mastodon last November, as a result of a Twitter migration, it turns out that people have been thinking about decentralized social networks for quite a while. Not only that, they’ve been building, experimenting, and creating things.
So this Sunday I’d like to present you with four articles that explain part of the history. This is a bit different than usual, these are not all flowing essays that you should read from beginning to end. Instead, try and skim through these articles, and focus on the parts that interest you, and skip the parts that do not.
I hope you can take away some of the following messages from reading parts of these articles:
- People have been working on decentralized networks for a long time. Actually, even way before the ActivityPub things that are the focus here.
- Creating a well-functioning network is hard, from a technical perspective.
- Creating a well-functioning network is even harder, from a social and people coordination perspective.
- Decisions made for practical reasons can have significant impact years down the line.
An interview with Evan Prodromou, one of the creators of ActivityPub
Evan Prodromou has been closely involved with ActivityPub. But also before that, @evan has an extensive history with building decentralized social networks.
This interview has him talking about all the projects that came before as well, and how this all flowed together into ActivityPub. @evan also has quite a few ideas and opinions on the current state of the fediverse as well.
If you only want to read one article of this list, I’d recommend you pick this one.
A Creator of ActivityPub on What’s Next for the Fediverse – The New Stack
ActivityPub meetings
If you really want to get in-depth knowledge on the history of how ActivityPub came to be, you should follow @robertwgehl, who is in the process of writing a book about it. The draft title explains it well “Move Slowly and Build Bridges: Mastodon and the Struggle for Ethical Alternative Social Media”.
He takes a scholarly approach, and spends time and effort on reading the notes of the meetings where the design decisions around ActivityPub were made. His main takeaways so far are interesting:
“the first thing that I found fascinating was a desire for and fear of established social media corporations (specifically, Twitter, Google, Facebook). The SocialWG stated again and again that they wanted Facebook or Twitter to participate – here is but one example of such a discussion – but there is also a strong fear of the work being appropriated or buried.”
He also notes the formation of distinct ‘camps’ within the group of people working on the ActivityPub standard:
“A final note, but an important one. There are three distinct “camps” in the SocialWG:
- An academic-focused group centered on SoLiD and semantic markup;
- People with previous federation experience, such as Pump.io folks,
- and IndieWeb, a group of folks who put the webpage at the center of everything.
I’ll say more about these groups and their competing visions in future posts.”
Reading the Minutes of the Social Web Working Group, part 1 – Robert W. Gehl.
Towards networks of consent
Christine Lemmer-Webber (@cwebbers) is also a co-author of ActivityPub. She is opiniated, with lots of great ideas, and a deep understanding of the fediverse.
This linked piece is not actually an article, it’s a ReadMe document on how to implement an improvement to ActivityPub. But it is not just a technical document, its a great explanation of why she is proposing some changes. And it turns out her understanding and explanations of why changes are needed are very insightful, and worth reading.
Some highlights:
The entire section called The Nation-State’ification of the Fediverse is worth reading! @cwebbers explains in detail how block lists result in large centralized instances, working against the proposed decentralization.
“It dawns on you: the easier approach isn’t a deny-list, it’s an allow-list (aka a whitelist). Why not just trust these five nodes? It’s all you have energy for anymore.
Except… what if you aren’t one of the five major nodes? Suddenly you see that other nodes are doing the same thing, and people are de-federating from you.”
On issues with Identify Verification and Authentification
“Unfortunately (mostly due to time constraints and lack of consensus), even though most of what is defined in ActivityPub is fairly clean/simple, ActivityPub needed to be released with “holes in the spec”. Certain key aspects critical to a functioning ActivityPub server are not specified.”
She then continues to explain how Identify Verification and Authentification are not specified. Fascinating to read if you’re technically inclined, but also worth knowing if you’re not: once you get down to the nitty-gritty details, turns out there are definite problems with important aspects of the protocol!
On follower count:
“So why on earth would we see follower counts also appear prominently on the federated social web, if these tools are generally built by teams that do not benefit from the same advertising structure? The answer is simple: it is what developers and users are both familiar with. This is not an accusation; in fact, it is a highly sympathetic position to take: the cost, for developers and users alike, of developing a system is lower by going with the familiar rather than researching the ideal. But the consequences may nonetheless be severe.
So it is too with how we build our notion of security and authorization, which developers tend to mimic from the systems they have already seen. Why wouldn’t they? But it may be that these patterns are, in fact, anti-patterns. it may be time for some re-evaluation.”
On where communities actually live:
“This seems to point at a mistake in assumptions about the federated social web: the instance is not the community level, because users may have many varying communities on different instances, and each of those instances may govern themselves very differently.”
OcapPub: Towards networks of consent – Christine Lemmer-Webber
As a bonus: ActivityPub explained with unicorns, centipedes and paper airplanes
The delightfully titled article ‘ActivityPub Eats Your Brain!’, by @a features a fun and whimsical explanation of what ActivityPub actually is. If you feel like its all a bit unclear, this might help. You can skip the code bits; while they are interesting and well explaining, you’re probably not the target audience.
The final part is also interesting for the more technically inclined people, @a explains how it works that there are actually two protocols: server2server and client2server. Mastodon for some reason only implements the first part, and so do most other projects on the fediverse.
The more technical focus might not make this article interesting for everyone, but I linked it because there is an important takeaway:
The software Mastodon, for a variety of reasons, does not use the entire protocol. And for other historical reasons, all the main forks have
That is all for now, thank you so much for reading. You can follow here at fediversereport.com or follow my Mastodon account.