When Mastodon surged in popularity in 2017, there was a palpable sense that the world was about to change. I found myself hopping between instances, scrambling to secure unique usernames on each one. In retrospect, it was a futile exercise—but more importantly, it was a textbook example of viewing something new through an old mental model. I couldn't escape the Twitter-era mindset of "first come, first served for handles."

The Limits of Mastodon's "Federation"

Mastodon's "federation" turned out to be decentralization dependent on server administrators, not user sovereignty. When a server shuts down, your identity and followers vanish with it. Yes, there's a migration feature, but it's "relocation," not true portability.

What Makes AT Protocol Different

AT Protocol is fundamentally different because it separates the data layer (PDS) from identity (DID). This means you remain the same person even if you move your PDS. Back in 2017, "decentralization" meant "multiple servers exist." The concept of "protocol-level decentralization" hadn't been articulated yet—so perhaps that futile scramble for handles was inevitable.

The Gap Between Technical Possibility and Reality

But a pragmatic question remains: Will users ever actually leave Bluesky Social's hosted PDS infrastructure?

Technical possibility and actual migration are two different things. Most users have little motivation to run their own PDS, and doing so requires technical knowledge and ongoing costs. Migration might happen if Bluesky Social makes policy changes that alienate users, if corporations and universities start offering PDS hosting, or if self-hosting becomes as trivial as registering a domain.

Ultimately, AT Protocol's value may not lie in "everyone migrating" but in the mere existence of that option deterring the concentration of power. Like nuclear deterrence, it functions precisely because it goes unused—a fascinating paradox.

"You Can Always Leave" as Brand Identity

Looking at Bluesky's official communications, there's a clear pattern of making "you can always leave" central to the platform's identity. Even without actual migrations happening, the stance of "we don't build cages" earns user trust and goodwill. Amid growing distrust of X/Twitter, this contrast works brilliantly.

But there's a fragility here. The "you can leave" identity only holds up when almost no one actually leaves. If mass migration ever became reality, it would represent ideological success for Bluesky Social—and simultaneously a business crisis. The success of AT Protocol as a protocol and the success of Bluesky Social as a company don't perfectly align. That tension simply hasn't surfaced yet.

The Optimal Strategy for Users

For individual users, hoping that Bluesky Social remains comfortable is the rational choice. Migration costs are high, and there's no guarantee that alternative PDS providers will remain stable. Enjoying the present while holding "exit insurance" is the realistic optimum.

For the ecosystem as a whole, however, the existence of alternative PDSes serves as an indicator of health. Movements like Eurosky and Blacksky emerge from specific community needs—data sovereignty, moderation policies, cultural autonomy.

In Japan, such movements have barely materialized. Possible reasons include: the fresh memory of Mastodon's "server proliferation followed by exhaustion," the tech community being comfortable enough within Bluesky Social, and the absence of any pressing need for "a Japan-specific PDS."

The Path from Ideal to Reality

Ideally, rather than corporations and universities creating official accounts on Bluesky Social, each institution would run its own PDS where affiliated members create accounts. This would be the vision most faithful to AT Protocol's design philosophy. A handle like @jack.example.ac.jp would serve as both proof of affiliation and identity—just like a university email address.

But this may be too maximalist. In practice, organizations lack motivation to take on PDS operational burdens, and "an official checkmark is good enough" becomes the default judgment.

A staged approach might work: first, widespread adoption of domain handles (possible without running a PDS), then organizations using these as official proof of affiliation, and eventually the emergence of demand for "we want to own our data too." Rather than working backward from the ideal, building up concrete examples seems more likely to work—especially in Japan.