Life as a Twitter refugee, a review of the Fediverse

I was recently inspired to take a break from Twitter after Elon Musk announced that he would be buying the company. I suppose I should talk a little bit about why that doesn't sit well with me, but I am more excited to recap my experience with the Fediverse as I sought to fill the Twitter void.

So first, to summarize my concerns with Twitter, there's really not much to it. It's not that I have something against Elon Musk in general. I don't always agree with him and I don't always disagree. However, he is the wealthiest person on the planet, and I think that's quite enough influence without owning the world's public communication forum.

No doubt, this is an uphill battle. If it's not one billionaire, it's another. So what's the point? It's a valid criticism. The current model is unsustainable in my opinion, but there is hope. Open standards are my reason for optimism. Specification standards (well-defined and commonly accepted API contracts) support coordination between systems that are independently operated. These standards have been largely missing from the social media space for its first two decades of existence. But no longer.

Quick Architecture Preface

We can't know everything about how the big social media platforms are architected because they don't share everything, though sometimes they share quite a bit. Regardless, we can make at least one pretty safe assumption: they're not hosted by just one computer. How's that for deep technical insight? :) But for real, large scale social media platforms are already distributed systems. Twitter doesn't have one giant volume on a single hard drive with every Tweet ever written. The data is split up across many machines, in many formats,

In other words, we think of Twitter as a single entity, mostly because it is a single entity from a corporate perspective. But from a technical infrastructure perspective, the universe of user-provided data is distributed. What if instead of one company owning the entire set of data, many companies owned certain parts, collectively becoming a federation of social media providers?

There's an immediate core challenge in this proposition. Each of the federated social media service providers would naturally need to coordinate with one another. We need to be able to query across providers, forward posts and DMs, etc. All of this coordination means we need some type of API specification for inter-provider communication. Presumably, today's major providers implement something like this type of coordination internally, but clearly they each have their own way to do it. If we want to federate across social media providers, we need a global standard.

The Proposed Standard

The ActivityPub protocol is a decentralized social networking protocol based upon the ActivityStreams 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

ActivityPub is an emerging standard, published circa 2017, but there is some important history of decentralized social media that predated ActivityPub. Notably, diaspora* lead the charge all the way back in 2010. Diaspora* was relatively successful in bringing concerns with centralized providers to light, though interoperability with other implementations never quite seemed to come to fruition. My speculation is that the developers of diaspora* were more focused on proving the viability of decentralization, not necessarily the viability of diverse and interoperable implementations. In 2017, the diapora* community discussed adopting the ActivityPub standard at length, but eventually decided against implementing the massive changes that would have been required. Still, the diaspora* community set the foundation for contemporary solutions.

Today, there are a few social media services based on the ActvityPub standard. A few of the most notable are Friendica, Mastodon, NextCloud, and PeerTube.  Unsurprisingly, each implements a subset of ActivityPub capabilities. An interesting report on which project implement which capabilities can be found here. In particular, I've found Mastodon to be most adopted and mature, so I focused my Twitter hiatus on that particular ActivityPub client.

I've been pleasantly surprised to find that the network is quite useful already, and honestly pretty vibrant with user activity. I have identified a few.. let's say... shortcomings of the network's current state that do feel detract from the user experience. In some later posts, I'd like to dig into those individually and brainstorm about some solutions, but for now, here are the themes:

  1. Discoverability - When you step into the ActivityPub world, at first, it feels very empty. It's not even necessarily that it is truly empty, but as a new user, you get very little help finding other users to follow. It's kind of great in a way, because you realize that nobody's telling what to be interested in, and that's an important aspect of this movement. But still, to gain adoption, we need to help users find content that interests them.
  2. Provider migration - As a user, I don't want to be stuck anywhere. That's almost the whole point. If I don't like policies that a particular provider implements, I want to be able to move easily. I tried this, and it was successful in basic sense. (You can find me here now.) However, it's not smooth experience yet, and the end result leaves some things to be desired.

I hope I can help, and I'll be looking for ways to contribute. Immediate next steps for me will be to dig into those two major user experience themes, and see if I can document some additional research and gather ideas from the community.

Lastly, I hope I don't regret this, but I suppose I can peek my head into Twitter since it is temporarily safe from the clutches of America's favorite brat. My wish for Twitter is that they chose to transform into an ActivityPub provider. That probably won't happen without some advocates inside their walls, so here goes... logging on again...

comments powered by Disqus