Introduction: The Hollowing Out of Promised Autonomy

Bluesky (AT Protocol) emerged as a "decentralized social media" platform, promising freedom from centralized platforms through DIDs (Decentralized Identifiers) using custom domains. With an identity like @yourname.com, users were told they would be liberated from centralized platforms like Twitter/X.

In reality, however, purchasing a custom domain through Bluesky becomes a revenue channel, while using your own existing domain requires DNS configuration effort. More fundamentally, regardless of how the domain is obtained, users gain only the symbolic appearance of independence. Platform control over infrastructure remains unchanged, and through the conflation of "ownership" and "usage rights," true autonomy is cleverly obscured.

This article analyzes ATP/Bluesky's three-tier structure (Units A/B/C), exposes the structural deception of the current system, and proposes a path toward genuine decentralization through "minimal autonomous units" similar to WordPress.

Part I: The Three-Tier Unit Structure and the Problem of "Unit B's Absence"

The Current Bluesky Ecosystem

The ATP/Bluesky ecosystem theoretically operates on three tiers:

Unit A (Fully Integrated Stack)

  • Entities like Bluesky Social (PBC) provide a vertically integrated service including PDS (Personal Data Server), Relay (data distribution), AppView (display/search), Feed Generator (algorithms), and Labeler (moderation)

  • Users participate as "consumers" and enjoy the platform experience

Unit B (Partial Infrastructure Provider)

  • Specific communities or regions independently operate intermediate layers like Relay or AppView

  • Bundles multiple PDSs to form local social networks

  • Theoretically envisioned as "Japanese-language Relay," "Academic researcher AppView," etc.

Unit C (PDS-Only)

  • Individuals run their own PDS on their servers, securing physical ownership of their data

  • However, without connection to Relay or AppView, they are effectively isolated from the network

The Critical Problem: The Absence of Unit B

Currently, Unit B barely exists. There is a massive gap between Unit A and Unit C, with no intermediate options. This structural flaw is the root cause of Bluesky claiming to be "decentralized" while functioning as a centralized platform in practice.

A comparison with WordPress clearly illuminates this problem:

WordPress succeeded because of the abundance of "shared hosting" as an intermediate layer. Even individuals with limited technical knowledge can run customizable websites with their own domains for a few dollars per month. In contrast, Bluesky offers only a binary choice: "Use Bluesky Social or build all the infrastructure yourself."

Part II: The Deception of DIDs as "Symbolic Autonomy"

What Has Custom Domain Actually Delivered?

At the core of ATP's design philosophy is the promise that "using a custom domain as a DID allows users to obtain a platform-independent, persistent identity." However, observing the reality reveals the following structure:

The Surface Promise

  • A custom domain like @yourname.com functions as a decentralized identity

  • A "portable ID" that can migrate across platforms

  • Return of data ownership to users

The Actual Implementation

  • Custom domains can either be purchased through Bluesky Social (monthly subscription) or configured via DNS settings for domains you already own

  • However, even when using your own domain, there are effectively no choices for PDS/Relay/AppView

  • Leaving bsky.social essentially disconnects you from the network

  • Since infrastructure alternatives (Unit B) don't exist, portability remains theoretical

  • In other words, the "form of domain ownership" (purchased via Bluesky vs. self-owned) is not the essential problem—the structure of infrastructure dependency is

In other words, users are purchasing the symbol of the string "@yourname.com," while the "autonomy," "freedom of choice," and "portability" that should underlie it are all empty promises.

The Decisive Difference from Email

This deception becomes even clearer when compared to Email:

Email: Substantive Decentralization

  • Custom domain + MX record configuration allows you to run your own mail server

  • Abundant choices: Gmail, corporate servers, rental servers

  • Low migration cost (DNS change only)

  • Messages are interoperable between providers

Bluesky: Nominal Decentralization

  • Custom domain + DID configuration appears to grant "autonomy"

  • But actual Relay/AppView choices are zero

  • Since migration destinations don't exist, effectively locked in

  • "Ownership" of data exists, but "usage rights" depend on the platform

Email achieves true federation where "each organization maintains its own server while enabling mutual message exchange." In contrast, while Bluesky emphasizes "data layer distribution," users remain subordinate to the platform through "computation layer centralization."

The Conflation of "Ownership" and "Usage Rights"

The fundamental deception in ATP's design lies in the intentional conflation of "ownership" and "usage rights":

  • Ownership is nominal: Even if your data exists on your PDS, it won't be distributed to the network without going through Relay

  • Usage rights are platform-dependent: Without AppView, data is "invisible"

  • Migration rights are theoretical only: Since migration destinations (Unit B) don't exist, portability is an empty phrase

This is like being told, "You own your house, but the roads, water, and electricity are monopolized by one company, and there's nowhere else to move to." Formal ownership is granted, but practical usability is controlled by the platform.

Part III: The Path to True Decentralization – Building a "WordPress-Style Ecosystem"

Three Conditions for Establishing Unit B

For Bluesky to truly become "decentralized," Unit B (partial infrastructure providers) must function as a viable ecosystem. Three conditions are essential:

1. Dramatic Reduction of Technical Entry Barriers

Current Relay/AppView implementations assume enterprise-scale infrastructure. This needs to be reduced to the level of "an individual setting up WordPress on a rental server."

Specifically:

  • Standard configuration launchable with Docker Compose: Bundle PDS + lightweight Relay + lightweight AppView + reverse proxy

  • Prevention of storage bloat: Differential sync + TTL-based automatic deletion (retain only "last 30 days + own posts + pinned")

  • Gradual scaling: Initially support 10 users, expandable as needed

  • Operation demonstration within 2GB memory, 20GB storage, 100GB monthly bandwidth

2. Building Economic Sustainability

For Unit B to operate long-term, appropriate revenue models are necessary. Volunteer-based approaches have limits.

Viable models:

  • Cooperative operation: "100 users × $1/month = $100/month" to maintain small-scale Relay/AppView

  • Micropayment layer: Prepaid credit system ("$1 for 100GB bandwidth + 10k post indexing")

  • Public goods subsidies: Universities, research institutions, NGOs operating as public infrastructure (utilizing research grants)

  • Specialized premium services: "Academic paper-focused AppView," "Photo-focused AppView" differentiated by added value

3. Design Philosophy of "Local-First + Global Search as Optional"

Not every unit needs to hold all data. Rather, a hybrid model of "self-sufficient within one's own community while connecting externally as needed" is realistic.

Hierarchical degradation model:

  • Layer 1: Personal Pod (PDS + local cache-type lightweight AppView)

  • Layer 2: Community Relay (partial Relay for geographic/thematic clusters)

  • Layer 3: Federated Index (opt-in cross-network search)

Proximity-prioritized gradual federation:

  • Default is local-first timeline (dozens to hundreds of units connected to the same Community Relay)

  • "Bridge units" (voluntary bridge nodes) loosely connect different clusters

  • Global search follows a "community library model": trusted third parties provide indexing services, and individual units query as needed (pull-based rather than push-based)

Specific Typology of Unit B

To concretize implementation directions, Unit B can be categorized as follows:

B1: Community Relay + Shared AppView Type

  • Operated by specific thematic/regional communities (e.g., "Japanese-language Relay," "Academic researcher Relay")

  • Connected PDSs: dozens to hundreds (membership-based)

  • Management form: cooperatives, NPOs, university clubs

B2: Managed PDS + Lightweight AppView Hosting Type

  • "Bluesky rental server"

  • Users have their own PDS but delegate infrastructure management

  • Pricing example: "$5/month for PDS + basic AppView + custom domain"

B3: Specialized AppView + Plugin Relay Type

  • Specialized for specific purposes (academic paper sharing, photo SNS, long-form posting, etc.)

  • Retrieves data from existing Relays + custom filtering/UI

  • Examples: "arXiv-style Bluesky," "Instagram-style Bluesky," "Medium-style Bluesky"

Directions for Technical Breakthroughs

Technical challenges for realizing Unit B can be addressed through the following approaches:

"Selective Subscription" Architecture

  • Relay supports not "full firehose subscription" but partial subscription via specific DID lists, hashtags, and language filters as standard

  • AppView uses not "complete indexing" but "partial indexing + caching strategy"

Collaborative Infrastructure Sharing

  • Multiple Unit Bs distribute Relay load: automatic routing by geographic location, time zone, and topic

  • DHT (Distributed Hash Table)-like search: efficiently resolve "post ID → which AppView has it"

Technology Stack for Lightweight Implementation

  • Repository differential sync: leverage ATP's commit-based design for BitTorrent-like peer-to-peer chunking

  • Bloom filter-based lightweight routing: probabilistic indexing without holding all data

  • WASM-based client-side processing: execute feed algorithms and moderation logic browser-side

Part IV: Phased Roadmap to Implementation

Phase 1: Standard Reference Implementation of Unit B-mini

Goal: Simplified implementation that technical communities can launch as "weekend projects"

Deliverables:

  • "10-user Relay + AppView" launchable with a single docker-compose.yml

  • Initial configuration via config.yaml specifying "PDS list to subscribe" and "other Unit Bs to federate with"

  • Operation demonstration within 2GB memory, 20GB storage, 100GB monthly bandwidth

  • Documentation: "Bluesky Unit B Operation Guide" (referencing Mastodon admin guides)

Duration: 3–6 months

Phase 2: Establishment of Inter-Unit B Connection Protocol

Goal: Different Unit Bs interconnect to form "a collection of small worlds"

Technical specifications:

  • Server-to-server mutual following: Unit Bs "partially share each other's local timelines"

  • Gossip protocol: exchange statistical information like "our Unit B has many posts on these topics" for efficient routing

  • Trust/Reputation system: distributed evaluation mechanism for spam and harassment countermeasures

Duration: 6–12 months

Phase 3: Unit B as Managed Service

Goal: Launch "hosting services" accessible even to non-technical users

Business model:

  • Cooperative services like "Bluesky Hosting Co-op"

  • Pricing example: "$3/month for PDS + local timeline + custom domain"

  • Open-source codebase (avoiding vendor lock-in)

Social organization:

  • Technical community develops "Unit B Operation Guide"

  • Share legal/financial operational know-how (cooperative law, non-profit incorporation, etc.)

  • Formation of international Unit B federation

Duration: 12–24 months

Conclusion: Beyond "Decentralization Theater"

The current Bluesky Social, while brandishing a "decentralized" banner, is actually constructing a centralized platform + nominal DIDs—a structure fundamentally no different from Twitter/X. The monetization of custom domains is merely payment for this "decentralization theater" that conceals the deception.

However, this doesn't mean ATP's design philosophy is fundamentally flawed. Rather, the problem is an ecosystem-building failure: the absence of Unit B as an intermediate layer.

Just as WordPress exploded in popularity through "shared hosting" as an intermediate option, if Bluesky can realize minimal units at "the level of setting up WordPress on a rental server" and an ecosystem where they interconnect, the path to truly decentralized social media will open.

This is technically feasible. The challenge lies in economic sustainability and social organization. When cooperative operational models, positioning as public infrastructure, and above all, the formation of user communities demanding "true autonomy" align, Bluesky's "promise" will finally become reality.

To see through the deception that conflates "ownership" with "usage rights," and to implement genuine autonomy—that is the challenge for next-generation social media.