Data Without Computing Is Not Decentralization

A Critique of Self-Hosting in the AT Protocol

One of the recurring claims around decentralization, particularly in social networking discourse, is that user data ownership is the primary problem to solve. The argument goes: if users control their data then power asymmetries naturally diminish. And, the argument isn't necessarily wrong, to be fair. The Authenticated Transfer Protocol (ATP) appears to take this idea seriously by design. Through Personal Data Servers (PDSs), users can self-host their identities, posts, and social graphs, and migrate them between services. That's pretty cool!

Despite this, I find ATP’s approach to decentralization incomplete. The protocol places strong emphasis on decentralizing data while largely sidelining the decentralization of the software and computation that operate on that data. In practice, these two concerns cannot be cleanly separated.

Data vs. Processing

ATP draws a conceptual boundary between user data and the applications that read from and write to that data. Users may self-host a PDS, while applications such as Bluesky, Pocket Blog, or other ATP services act as intermediaries that provide interfaces, ranking, indexing, moderation, and discovery.

This separation is often presented as a strength: users can move their data freely while applications compete at the service layer. However, decentralization is not only about where data resides—it is also about who controls the execution environment that interprets and mediates that data.

On ActivityPub, these layers are inseparable: user data lives inside databases operated by server software such as Mastodon, Misskey, PeerTube, etc.. Those same servers perform the computation necessary to participate in the network. If you want autonomy in the Fediverse, you run a server. Data storage and processing are bound together by design (or limitation).

ATP, by contrast, treats data ownership as the primary decentralization objective, while treating application hosting as a secondary or optional concern.

A Computing Analogy

I think a useful way to think about this difference is through a computing metaphor.

In ATP, a PDS is analogous to owning your own /home directory: you control your files, you can move them between systems, and no single service can permanently lock you out of them. This is an improvement over traditional platform models!

However, owning a "/home directory" does not mean you own a "computer".

The implicit assumption in the ATP ecosystem is that users will attach their "/home directory" (PDS) to someone else’s machine, usually one operated by a small number of large application providers (like Bluesky). The status quo prioritizes data custody while leaving the question of computation mostly de-facto centralized.

In ActivityPub, the metaphorical /home directory and computer are inseparable. I.e.: if you host a Fediverse instance, you operate both (data + processing). If you leave, you must provision another system yourself and do heavy database surgery or otherwise lose access to previous data and start over from scratch. There are no PDS implementations in ActivityPub (right now, anyway) that allow for seamless, by-design nomadic data migration. This arrangement is less flexible, but it facilitates decentralization that applies to both storage and execution since a Fediverse instance is a server with a database.

Why Self-Hosted Software Matters

The Fediverse defaults to self-hostable software. ActivityPub applications are designed from the outset to be deployed by third parties. Their code is public, their installation paths are documented, and their maintenance expectations assume independent operators. Many have reached "appliance" levels of deployment either through containerization or straightforward .deb packages that just require being connected to a database and web server. This is why tens of thousands of independent ActivityPub instances exist today.

What feels missing in ATP is a similar expectation around software.

I do not only want to self-host my posts, blogs, or listening history (my user data). I also want to self-host the software that renders, indexes, moderates, and exchanges that data. I want to run my own ATP-compatible microblogging service, my own long-form publishing instance, and my own social infrastructure for myself or a small group of users.

At present, this mode of participation does not appear to be a primary design goal or consideration within the ATmosphere.

Nomadism Without Infrastructure

ATP is often described as enabling nomadic identities. Users can migrate between services without losing their data or social graph. Conceptually, this is appealing!

However, in practice, migration requires destinations. And, the ATmosphere doesn't make building "destinations" very straightforward or easy.

While there may be thousands of PDS hosts, and while PDS hosting is now very easy and straightforward, there are relatively few independently operated ATP application instances. Most meaningful interaction flows through a small number of centralized services. The ability to move data matters less when there are limited places to use it, or more daunting and undocumented efforts of building the places oneself where one can use that data.

Decentralization requires not only exit rights, but also a diverse ecosystem of independently-run systems that users can realistically join.

Software as a First-Class Concern

None of this is an argument against PDSs. User-controlled data is a real improvement over previous models. The issue is that decentralization stops short if it focuses exclusively on storage.

Software determines moderation rules, ranking algorithms, discovery mechanisms, and social norms. Decentralized software also provides for censorship resistance and network robustness. Centralizing these functions while decentralizing data still concentrates power and forms network bottlenecks.

What I would like to see in the ATP ecosystem is a clear expectation that applications themselves should be routinely self-hosted. Thousands of ATP-compatible application servers alongside tens of thousands of PDSs, all interoperating within a shared protocol space.

That is what decentralization looks like in operational terms.

Closing

It is possible that these concerns will be addressed as ATP matures, or that I am misreading the project’s trajectory. From the outside, however, the emphasis appears clear: self-host your data, rely on centralized services for everything else.

History suggests that power accumulates where computation occurs, not merely where data is stored. If ATP aims to avoid reproducing existing platform dynamics, the self-hosting of applications needs to be treated as a core requirement rather than an optional extension.