In the first two issues of this series, I explored the mapping of Web3 social frameworks, focusing on its protocols, identity layers, and app layers. In issue #2, I attempted to explain the major differences in philosophies at the infrastructure layer, including protocols and identity projects, compared to those at the app layer. This month, we will zoom into the protocol layer, specifically focusing on decentralized social media as a distinct category of protocols.

Web3 wasn't created in a vacuum; it is part of broader trends, one of which is decentralized social media. In Part 1, I want to provide the broader context of decentralized social protocols and platforms that have been emerging outside of Web3 for more than a decade, driven by the Open Source Software (OSS) community. Armed with this knowledge, we'll then move to Web3-native protocols and try to draw conclusions on what new things they might bring to the table.

The Dawn of Decentralized Social Media

As early as 2008, the digital world started seeing the emergence of decentralized social media platforms. At this time, tech giants like Twitter and Facebook were beginning to capture the online social networking scene. Yet, these centralized platforms, with their proprietary code and tendency to commodify user data for shareholder gains, didn't sit well with many in the open-source software (OSS) and hacker communities. These groups yearned for platforms that would give users control over their online presence, enabling them to own their data and their experience.

This call for decentralization led advocates like Evan Prodromou and his team to develop alternatives. Their contribution, GNU Social, aimed to stand as a beacon against centralized platforms. It "helps people in a community, company, or group exchange short status updates, conduct polls, announce events, and engage in other social activities." Conceptually, GNU Social functions like Twitter: users can post and read status updates. However, the difference lies in its decentralized nature. With GNU Social, individuals can run customized versions of the software on their servers and join a wider network.

This approach empowers users to choose and use diverse clients or web interfaces, and importantly, host their data independently, similar to the higher levels of decentralization seen in the email network. Technically inclined individuals can host their own mailboxes, while others might rely on major platforms like Gmail or Outlook. Such networks, characterized by distributed but interconnected nodes, are called "federated networks.”

“Federated networks let users pick a server to sign up with, which gives them access to the entire network spread out across many different servers. This gives users more choices for applications, policies, and community cultures. Email is an example of a federated protocol that everyone on the internet uses. Gmail is a popular email application, but if you use a different provider you can still communicate with anyone with an email address.”— Jay Graber, Decentralized Social Networks, Comparing federated and peer-to-peer protocols, 2020

Operating under the OStatus protocol, GNU Social allows disparate social networks to communicate, forming what is known as a "federation." This model contrasts sharply with centralized networks, such as Twitter, where one entity dictates platform rules and holds all user data. It's also distinct from a pure peer-to-peer system, where every user is a node in the network.

The Early and Fragmented "Fediverse"

First public record of mention of the name “fediverse”

The 2010s were a period of experimentation for the federation model and the emerging 'Fediverse'. New federations like Diaspora, a Facebook alternative developed by a team of MIT students, were put out there and were subsequently handed off to their community for further development. We could also mention Zot protocol, which added encryption and private messaging to existing standards.

In this organized chaos, a specific branch of protocols began to outpace the others. It started with OStatus, evolved into the pump.io protocol, and eventually led to ActivityPub, which is arguably the most widely-used decentralized social protocol at the time of writing. Each iteration aimed to learn from its predecessors to eliminate inefficiencies and facilitate greater interoperability.

https://en.wikipedia.org/wiki/Fediverse - Excerpt of common protocols and platforms in the Fediverse (2023)

You might have heard of ActivityPub when Meta announced its interest in integrating with the protocol or if you have ever explored decentralized alternatives Twitter like Mastodon, the leading app in this space. Other projects, such as Tumblr and Flickr, have also recently expressed interest in ActivityPub.

ActivityPub and Mastodon Take Over the Fediverse

Now that we've set the stage for the rise of ActivityPub in the decentralized social media landscape, let's explore how it works, what contributed to its success, and what its limitations might be. I highly recommend this podcast with Evan Prodromou.

The Protocol

The protocol capabilities include sharing profiles, posts, photos, videos, comments, replies, reactions, likes, and favorites—essentially all standard social media interactions you can find on centralized web2 platforms.

The protocol standards focus on two main areas:

  • Standards for data representation: these detail events in a JSON data structure, such as "Alice liked Bob's post."
  • Standards for data distribution: these outline the mechanisms for routing activities throughout the network.

The Network

The network consists of a federation of servers that comply with the ActivityPub standard and communicate with each other. A server running ActivityPub is referred to as an "instance." These instances are most commonly run by hobbyists and can host anywhere from a handful to tens of thousands of users. They handle both usernames and their associated data while interacting with other instances. Server admins can unilaterally enforce moderation policies and can block other instances from interacting with their users. For example, gab.com, a right-wing extremist website, has its own Mastodon instance but is generally blocked from most of the Fediverse.

The Data

In most cases, user identities and data are tied to the server, meaning that if the server shuts down or a user chooses to migrate to another instance, most of the data and content will be lost. Additionally, content is usually not encrypted, and admins may have access to their users' messages.

Monetization

Mastodon's development is supported by a Patreon, bringing in about $300k annually. This allows the founder, Eugen Rochko aka Gargron and small team to work on Mastodon mobile apps, instance hosting 700k people and main protocol development.

Each instance is funded by its own administrator or the community often through donations.

Mastodon, the Largest ActivityPub Implementation

If ActivityPub has become the main standard towards which projects are converging, Mastodon, created in 2016 and incorporating ActivityPub in 2017, is emerging as its primary implementation and ambassador.

Eugen Rochko, the founder and lead developer, has modified the standard to suit specific needs and user demand for features. Its appeal has led most software projects to seek compatibility with it. Today, Mastodon supports many clients and web interfaces, but its custom implementation of the protocol is increasingly serving as a core backend that others can build upon.

As shown on the graph above, Mastodon’s growth has accelerated when Elon Musk bought Twitter and introduced paid access to its third-party API in early 2023 besides other abrupt changes causing FUD. As a result, users and teams have flocked to Mastodon and started developing third-party apps compatible with it.

Among the companies that have explored Mastodon are Mozilla with mozilla.social, Medium with me.dm, and Flipboard with Flipboard Social. Users of these services can access instances using their existing logins.

Pros and Cons of Mastodon

Below is a table summing up the Pros and Cons of Mastodon according to Evan Prodromou as of 2023:

It's worth noting that cultural wars, toxicity towards minorities, and moderation issues have sparked significant debates within the Fediverse, as pointed out in this 2023 article by Leonora Tindall. Moderation continues to be a sensitive topic, and concentrating too much power in the hands of server admins may not be the best solution.

Where are non web3 decentralized social media going next?

Over the past decade, the rise of decentralized social media has been a gradual, yet persistent phenomenon. It started as an alternative answer to platforms like Twitter, and over time, multiple experimental platforms took shape based on the federation model. Eventually ActivityPub protocol became the central piece.

Interestingly, many Web 2.0 entities are showing interest in joining the Fediverse. Their participation, however, won't be without challenges. Ensuring interoperability between existing Fediverse platforms and these major companies might be tricky. Furthermore, centralized entities, due to their inherent business models, often find their interests at odds with the principles of decentralization. This misalignment might limit their full adoption of the federated model.

The future trajectory of Mastodon remains uncertain, especially in relation to challenges such as user onboarding, scalability, and content moderation. Even centralized social media networks posessing vast resources grapple with these issues and may never solve them. Currently, Mastodon a few million users millions, primarily made of tech-savvy individuals from open source and hacker communities, artists, and marginalized groups seeking a more inclusive online space. Yet, many questions remain: How will Mastodon cater to the next hundred million users? How can it monetize effectively at scale, increase its development and feature rollout pace, and compete with the next 'super app'?

In PART 2. - web3 native decentralized social media protocols

In Part 2, I'll explore Web3 native social media protocols like Farcaster and Lens. We'll be able to compare the pros and cons of these protocols with their non-Web3 counterparts and hopefully draw some interesting conclusions from this.

-----

Bonus Section: A Glimpse into AT Protocol and Nostr as Emerging ActivityPub Alternatives

In this bonus section, let's briefly explore AT Protocol and Nostr, two rising alternatives to ActivityPub.

AT Protocol - video here (link)

Crafted by the Bluesky team, AT Protocol is still in the development phase, with Bluesky operating the only existing instance as of now.

  • AT Protocol, short for Authenticated Transfer Protocol, differs fundamentally from Mastodon in that it separates a user's identity from their data.
  • Within the protocol, each user has a Decentralized Identifier (DID) and a Personal Data Server (PDS), structured as a Merkle tree. All user documents reside in the PDS. This single PDS is interoperable with all apps across the ecosystem.The DID is a URL and is globally unique, like "justingarison.com," for example.Ownership of the server equates to ownership of the data. However, it's worth mentioning that deletions are not possible as the PDS is public, and actions like "likes" are permanent.
    • This single PDS is interoperable with all apps across the ecosystem.
    • The DID is a URL and is globally unique, like "justingarison.com," for example.
    • Ownership of the server equates to ownership of the data. However, it's worth mentioning that deletions are not possible as the PDS is public, and actions like "likes" are permanent.
  • Applications that interact with AT Protocol employ crawlers to access information in your PDS. The size and scope of these crawlers could expand as more Personal Data Servers are added to the network, presenting a potential for abuse.

Nostr

  • Instances on Nostr are called ‘relays’
  • Nostr allows users to subscribe to various relays.
  • Revenue from ads is directed to content creators, who can also earn tips.
  • Users have the ability to view any feed in a read-only mode through the public key of the feed's owner.
  • Direct messages are encrypted for privacy.
  • Nostr operates on a public-key architecture with relays or nodes responsible for storing content.
  • Relay administrators have the power to moderate content.
  • To ensure freedom from censorship, you have the option to host your own Nostr relay.
  • The primary iOS client for Nostr is Damus, with astral.ninja serving as another client option.
  • Challenges facing Nostr include insufficient incentives for running relays, lack of resistance to Sybil attacks (currently employing a solution similar to Keybase), potential network fragmentation, inadequate data availability infrastructure, and a limited range of curation algorithms.

Sources;

Going further: