If you’ve been following the discussion around Bluesky even just superficially, you’ll have heard this mantra repeated: “your data is yours, you can take it with you whenever you want, no lock-in”. It’s a wonderful promise that is also, at least for now, only half true.

The protocol behind Bluesky – the AT Protocol – does indeed guarantee portability, but not completely, at least in some of its possible applications.

Let’s see why.

The architecture

The basic idea behind the AT Protocol is powerful: the data belongs to the user, not the server. Thanks to cryptographically signed repositories and decentralised identifiers (DIDs), each account formally owns its own posts, followers and identity, and can, in theory, migrate from one Personal Data Server (PDS) to another without losing anything.

The architecture rests on four pillars:

1. the PDS, where the user’s raw data resides;

2. the Relays, which aggregate and redistribute that data;

3. the AppViews, which index, interpret and transform it into what we see within the app;

4. the PLC Directory, the register that keeps track of the unique identifiers for each account.

The problem is that the value does not lie in the raw data; it lies in the way it is interpreted and presented. And it is precisely there, at the level of the AppViews, that the real business battle is fought.

A promise only partially kept

The weak point in the promise of total portability lies in the AppViews and the so-called custom lexicons. Lexicons are schemas that allow each application to define its own functionality; they are technically open and can be published by anyone, but if, in practice, only one provider implements them in their own AppView without making them available to the community, the result is that the data linked to those functionalities becomes unreadable - or at any rate meaningless - for any alternative client.

There is therefore no lock-in on the raw data, which remains portable. However, there is a lock-in on functionality and user experience: you can transfer your PDS but leave behind everything that made that app unique in terms of user experience and additional features. The protocol guarantees the portability of raw data, not that of the value added by the service, and it is precisely that added value that is the focus of the business.

The Overwhelming Presence of Bluesky

Bluesky was the first practical implementation of the AT Protocol and represents the paradigmatic example of the critical issues highlighted above – but not only that.


  • The vast majority of accounts reside on Bluesky’s infrastructure. The company’s Transparency Report 2025 reports a 60 per cent increase over the year, from 25.94 to 41.41 million registered users, including both accounts hosted directly by Bluesky and the thousands of independent PDSs managed by third parties within the federated network; however, the vast majority remain on Bluesky’s infrastructure.

  • The core lexicons — those defining posts, followers and likes — are developed and versioned in Bluesky’s GitHub repository.

  • The PLC Directory, the identity registry, is currently managed by Bluesky Social PBC, although in 2025 the company announced plans to transfer it to an independent organisation precisely to ensure neutral governance.

And it is no coincidence that control is concentrated where the capital lies. Bluesky has raised a total of $123 million, culminating in a $100 million Series B round led by Bain Capital Crypto, with Alumni Ventures, Anthos Capital, Bloomberg Beta, the Knight Foundation and True Ventures rounding out the round. Investors do not fund a protocol out of philanthropy; they expect a return, and that return cannot come from portable data but stems from the exclusive services and features that only an AppView with proprietary custom lexicons can offer.

The most recent sign pointing in this direction came on 9 March 2026: Jay Graber stepped down as CEO of Bluesky, replaced on an interim basis by Toni Schneider, a venture capitalist.

The Bluesky client is open source, licensed under the MIT licence – anyone can download it, modify it or fork it. However, the AppView – the server-side layer that indexes the firehose and serves the content, the true heart of the value – has, as far as I am aware, never achieved the same level of openness: community developers have long reported that Bluesky’s full AppView remains largely proprietary, with the promise of an open-source release having been ‘coming soon’ for years. This is practical confirmation of the underlying argument: the raw data layer and even the client-side code are open, but the layer that actually generates value is far less so.

The example of Tangled

The Finnish start-up founded by brothers Akshay and Anirudh Oppiliappan, which is building an alternative to GitHub based on the AT Protocol, has raised €3.8 million (approximately $4.5 million) in a round led by byFounders, with Bain Capital Crypto, Antler and high-profile angel investors such as former GitHub CEO Thomas Dohmke. The raw code remains in the PDS, so it is formally portable — but features such as the **Spindle** CI system, based on a micro-VM, reside in the AppView layer. The practical result is a real risk of lock-in regarding the user experience, which is structurally identical to that of GitHub, only with a ‘decentralised’ label stuck on top.


Governance is the real battleground

Things are moving on the standardisation front: in September 2025, the AT Protocol was submitted to the IETF as an Internet Draft, and in January 2026, the charter for the official working group, named **Authenticated Transfer (ATP)**, was published.

This is a real step towards a neutral home for the base protocol.

But it is not enough; in fact, standardisation only concerns the base protocol – that is, repositories, synchronisation and general architecture. The application lexicons - the features that actually create value - remain outside the scope and under the control of those who developed them, be it Bluesky, Tangled or anyone else.

The contradiction is clear:

  • opening up the core protocol benefits everyone, because a larger ecosystem brings more users to all;

  • opening up the application lexicons, on the other hand, harms those who built them, because anyone could replicate those functionalities and erode their competitive advantage and ability to generate value.

As long as this remains the case – that is, as long as the protocol’s governance remains in corporate hands and there is venture capital to be capitalised on – the scope for true decentralisation and data portability is significantly reduced.

The underlying lesson

Current implementations of the AT Protocol demonstrate one simple thing: opening up the protocol is necessary, but it is not enough. Data portability and the user’s complete control over their data are a genuine achievement; however, this does not eliminate dependence on the services that make such data usable. IETF standardisation is a real step forward, but it does not reach the level where economic value is generated.

The only real protection in an ecosystem such as this depends on three conditions:

1. multiple, competing open-source applications running on the same protocol;

2. accessible self-hosting for every component of the infrastructure, not just for the most experienced developers;

3. standardisation of lexicons at community level, through a truly neutral body.

Without these three pillars, any ‘open’ protocol risks being reduced to a mere vehicle for transporting data that only a few proprietary AppViews can read and enhance with exclusive, paid-for features.

The paradox of Bluesky and the AT Protocol – and, more generally, of any open protocol built within a venture-capital-driven ecosystem – is that theoretical decentralisation and portability do not automatically translate into practice. The openness of the protocol does not eliminate the risk of lock-in but shifts it upwards: from the data level to that of functionality and user experience.

The fundamental question, then, is not technical but political: who controls the standards, and in whose interest? As long as the answer remains ‘those who have invested capital and need to make it yield a return’, the freedom promised by open protocols will remain only a half-promise.