I am inaugurating a series analyzing social media platforms from a technical perspective, where I will share detailed technical insights about decentralized social networks.

Today, we begin with BlueSky (bsky), a decentralized social platform very similar to Twitter. It is based on the AT Protocol and allows for greater control over user data and content moderation.

I have divided this text into three parts. In the first part, I discuss today’s migration of Wyborcza’s editorial team to BSKY. In the second part, we will consider why, if we’re moving towards more ethical and decentralized solutions, they chose a commercial platform over Mastodon. In the third part, I will explain the nature of this supposed decentralization.

Part 1: Arguments for leaving X - The case of Gazeta Wyborcza

Today (November 28, 2024), Gazeta Wyborcza announced its decision to suspend activity on platform X (formerly Twitter) and transition to Bluesky. Let’s examine their arguments in detail.

Disinformation and account authenticity Issues on X

The X platform has undergone significant changes in its content moderation approach following Elon Musk’s acquisition. The platform’s algorithms actively promote controversial and emotional content, which has led to increased visibility of fake accounts operated by internet trolls. The user verification system, following the introduction of Twitter Blue subscription (now X Premium), has failed to maintain its original purpose of distinguishing authentic accounts from fraudulent ones. Moreover, the platform has become vulnerable to organized disinformation campaigns, including those sponsored by foreign entities (China, Russia). In my observation, X has become a repository of endless conspiracy theories, many of which are amplified by Musk himself.

Reach restrictions for publishers

The current business model of X, like most social media platforms, is built around retaining users within the platform ecosystem. In practice, this means that posts containing links to external websites receive significantly reduced organic reach, deliberately discouraging users from leaving the platform. For media organizations whose primary objective is directing readers to full articles on their own websites, this presents a serious impediment to effective communication and platform promotion. Content narratives are increasingly confined within social media services, leading to progressive centralization and platform dependency. Furthermore, platforms increasingly prioritize content created by influencers and artificial intelligence, relegating professional journalism to a secondary position.

Advantages of Bluesky as presented by the Editorial Team

According to Wyborcza’s editorial team, BSKY offers a more transparent content display system. Users can view posts in chronological order, without interference from algorithms that promote specific content. Importantly, the platform does not penalize the sharing of external links, which is crucial for publishers. Additionally, BSKY’s interface closely resembles classic Twitter, facilitating a seamless user migration experience. The most significant difference, however, is moderation and the feed recommendation system, a truly community-driven algorithm.

Part 2: Why not Mastodon?

A natural question in the context of seeking a decentralized alternative is: why didn’t the editorial team choose the federated Mastodon network? It’s a microblogging platform offering true decentralization through the ActivityPub protocol, yet Wyborcza opted for a different solution. Let’s analyze the potential factors that might have influenced this decision.

Technical barriers

The federated nature of Mastodon requires users to understand the concept of instances and make decisions about server selection. For the average newspaper reader, this can present a significant barrier to entry. The federation system, though technically considered perfect by its supporters, is more challenging in terms of marketing communication and may discourage less technically-inclined users.

Business aspects

Mastodon is characterized by significant dispersion of users across different instances. In practice, this can make it difficult to build a cohesive community around publisher content. Additionally, the lower presence of key information sources, such as politicians and public institutions, limits the ability to quickly respond to current events.

Identity verification limitations (one of the critical aspects)

It is important to note that Mastodon’s architecture has a significant weakness in its identity verification system. In this federated, decentralized system based on ActivityPub, each instance independently manages its users’ identities, which makes it challenging to definitively verify account authenticity across the entire network. In an era of disinformation and manipulation, this presents a significant challenge for media organizations and public figures. Indeed, this concern was fundamental to Wyborcza’s departure from X - Mastodon lacks a mechanism for definitively confirming that an account truly belongs to a specific organization or public figure.

This decentralized approach to verification becomes problematic in the context of professional platform utilization. I will discuss the details of rel-me verification and GPG in my forthcoming SWOT analysis of Mastodon. This solution provides no centralized identity registry, and can be easily undermined by creating similar-looking accounts on different instances. For media organizations and public figures, this approach fails to provide sufficient levels of credibility and recognition across the entire network.

A more detailed analysis will be presented in a separate SWOT publication about Mastodon. Where I will provide examples.

Part 3: Technical architecture of BlueSky’s federation model

The AT Protocol’s implementation in BlueSky creates a federation model that maintains significant central control points. To understand why this system isn’t truly decentralized, we need to examine its core architecture (i hope i understand it properly).

Core architecture components

This architecture reveals three critical centralization points in BlueSky’s implementation:

The Identity System serves as the central authority for all user authentication and verification. Even self-hosted Personal Data Servers (PDS) must validate their identities through BlueSky’s DID service, creating a fundamental dependency on BlueSky’s infrastructure.

The Relay Service acts as a mandatory intermediary for all federation traffic. Unlike truly decentralized systems where servers can communicate directly, every interaction between PDSes must flow through BlueSky’s central relay. This creates a single point of control for all network communication.

The AppView Service centralizes content distribution and filtering. While users can implement custom feeds, the underlying data flow remains dependent on BlueSky’s infrastructure for distribution and access.

BlueSky limits AT Protocol’s decentralization potential

This architectural design ensures that while organizations can host their own PDS instances, true independence from BlueSky’s infrastructure remains impossible. Every component in the network – whether it’s an official BlueSky PDS, a self-hosted instance, or a third-party implementation – must maintain constant synchronization with these central services to participate in the network.

My analysis reveals that BlueSky’s architecture represents a federated system with central control points rather than a truly decentralized network. While it offers greater flexibility than traditional centralized platforms, it maintains significant control through its essential infrastructure services. Operating your own PDS provides some control over physical data storage and export capabilities, but it falls short of the true independence offered by genuinely decentralized protocols like ActivityPub, NOSTR or Matrix. The system demonstrates technical maturity through advanced features, including effective moderation, community-driven algorithmic information channels, and seamless account migration between PDS instances. These characteristics have made the platform particularly attractive to editorial teams and politicians in Poland.

Identity Verification System

BlueSky introduces a significant innovation with its DID (Decentralized Identifiers) system, which enables reliable identity verification across the entire network. The system supports two verification methods: did:plc (BlueSky’s internal system) and did:web, which allows organizations to utilize their own internet domains. The latter option is particularly crucial for publishers and public figures - media organizations can use their own domains (e.g., @editor.newspaper.com) as verified identifiers.

In my assessment, domain-based verification provides a high level of credibility since it requires control over the domain, making it particularly valuable for journalists and politicians who need to confirm their accounts’ authenticity. It also enables verification revocation when necessary. While the system offers flexibility in identity verification, it’s important to note that this doesn’t alter the platform’s centralized nature - all network operations still require mediation through BlueSky’s central infrastructure.

Conclusions: implications for publishers

In upcoming articles in the series dedicated to social platforms, I will present a detailed SWOT analysis of the Mastodon app and ActivityPub protocol and a comprehensive review of the NOSTR protocol. Particularly interesting will be the analysis of the latter solution, which presents a different approach to social network decentralization, based on cryptography and distributed architecture.

Sources

AT Protocol

Wyborcza: We’re Leaving X, See You on Bluesky

Krytyka Polityczna Says Goodbye to X/Twitter

• Social Media
• Decentralization
• BlueSky
• Mastodon
• AT Protocol
• Fediverse