A Plan for Social Media - Intro

About 18 months ago, Mozilla announced that they would explore a healthy social media alternative. Their started their efforts by setting up a server and putting up together a team to work on new applications for the ecossytem. Fast-forward to February of 2024, and they released a memo which said:

Our initial approach was based on a belief that Mozilla needed to quickly reach large scale in order to effectively shape the future of social media. It was a noble idea but one we struggled to execute. While we resourced mozilla.social heavily to pursue this ambitious idea, in retrospect a more modest approach would have enabled us to participate in the space with considerably greater agility.

The more cynical of you would be quick to argue that this memo is mostly corporate talk to justify their poor management decisions of the last years and to give them an excuse to jump into the AI bandwagon.

But then, there is this:

How healthy is a network that loses 40% of its active users in 10 months?

How healthy is a network that loses 40% of its active users in 10 months?

It seems that no matter how badly the tech companies screw up and no matter how many people show complete dissatisfaction with the status quo, the Fediverse as a whole keeps “struggling to execute”. Does this mean that Mozilla is right to just get out of the space altogether? Should we just give up on the idea of a healthier social media landscape? In this blog post, I’d like to make a deeper analysis of the core pieces of the Fediverse and:

  • show how Mozilla’s approach was flawed and unlikely to succeed even if they had more substantial growth
  • propose a different approach that “can be executed with greater agility”
  • make a pitch for potential businesses and players in the space who still see value and an opportunity to take back the social web.

Get comfy in the chair, because this is looking like a mini-series…

Mozilla’s mistake and the Pachyderm in the Room

Despite Firefox’s constant slippage in market share, Mozilla still has considerable influence as one of the stewards of web technologies and is widely regarded as the only large institution in the standard bodies acting with the best interests of people in mind - in contrast with the likes of Google and Microsoft, who are seen as pushing for the development of technologies that mostly serve their own agenda. So, when they announced their plans to explore the Fediverse, one could reasonably expect them to take a look at ActivityPub (after all, it is already a W3C standard) and join in the efforts to make technologies that leverage the protocol directly. It would have been completely aligned with their mission if they had, e.g, decided to use Pocket as a laboratory for “social web” features based on ActivityPub.

Instead, they announced they would be launching their own Mastodon instance. While at first this seemed like good news (Yay, look at who is joining us to the party!), this gradually has shown to be completely backwards in regards to a reasonable strategy. Let us count the ways:

Mastodon is too opinionated and makes for a bad experimental system

This is not something to blame the Mastodon developers for; what they managed to create with such a small team is actually impressive. But if Mozilla’s goal was to “explore a healthy social media alternative”, it would make a more sense if they started with something that could let them be more flexible.

For example, Mastodon (as most of the current Fediverse software) assumes that one server will only work for one domain, and that everyone’s identity will be tied to this domain. There is no system nowadays with a good solution to identity portability is non-existent. The best that Mastodon can do is simply to let people take their data from one server to the other, but the identity itself is not in the user’s control.

Mastodon has almost no regards to ActivityPub interoperability

Despite being the poster child of the Fediverse and arguably the AP-system with the most users, the implementation of Mastodon lacks in support for common Activity Types, deviates from the standard whenever following it could be a problem for its internal implementation and is known for discarding or ignoring messages from other software when they are not in the “happy path” of Mastodon implementation. For example, Mastodon still lacks good support for groups, which makes it very difficult to follow a Lemmy community from it.

The strongest signal that ActivityPub is a second-class citizen for Mastodon is the fact its clients - from its own web UI to mobile apps done for other Fediverse projects - prefer to use the HTTP API provided by the server instead of accessing ActivityPub’s “native” endpoints.

The Social Web is more than just microblogging

Mastodon is, first and foremost, an open source clone of Twitter. It was designed to work around the idea of short text messages, with the occasional embedded link or image. If you are a video streamer who wants to share your content, the people on Mastodon will see it as a “post” with a link to the stream. If you write software that shares the music you’d be listening to and you were planning to use it as some alterantive to the “audio scrobblers” like Last.FM, every song would become a post in a stream. There is no way for a user in Mastodon to say “feel free to ignore these types of activities”, because basically every activity gets converted to a “Note” type.

Big instances, big problems

One of the most common analogies for federated services is “it works like email. It doesn’t matter on what server you are, you can talk with anyone who is connected to it”. The analogy works well until you find out that for one reason or another your server got involved in some blocklist. Or your server admin got into a fight with some other admin and they severed ties and took their entire communities as hostages. Or some Japanese script kiddies got an account at your usually well-managed server and is using it to send spam messages to everyone, and other admins now are treating your instance as radioactive.

One unfortunate consequence of the “one server = one domain” equivalence of the current services is that there is no way for someone running the server to separate its users. The whole server needs to be constantly monitored and any slip from the moderation team (which are most of the time just a bunch of overloaded volunteers) could lead to its reputation being destroyed.

To sum up: there was no actual need for yet-another Mastodon instance on the Fediverse. There was nothing novel about it to bring new people to it and by putting energy into this top-down approach was a misfire.

In the next blog post, I’ll do my best to show I’m not a Negative Nancy, and we’ll make a quick dive into ActivityPub and see if by understanding some of the fundamentals we can come up with an alternative approach with better chances of success.