ATProto claims to provide a decentralized way of publishing content, but it fails to solve a problem that wasn’t already solved by openly governed standards. It also does it in a less efficient and direct way than open protocols do. A better solution would have used open standards and solved the REAL blocker for decentralized web adoption, which is to make self-hosting easy enough that your boomer mom could do it.

Open Web Standards

There are already several protocols developed by non-profit industry standard groups, which if taken together, could accomplish what ATProto does, but BETTER. One implementation that I particularly like would leverage Atom, WebSub, and optionally OAuth to create a push based publishing node. This would be complimented by a discovery index, an idea you will already have experience with if you’ve used Apple Podcasts.

Atom is RSS, but with more collaboration from the wider web in its definition. It’s a simple feed format that gets the job done in a direct and easy to understand way. Almost any content data store could be exposed as an Atom feed. There’s no need to have a specially designed or engineered “Persona Data Store;” any blog, any news website, any social media feed could be expressed as an Atom feed. In an imagined implementation, the Atom feed wouldn’t publish the content directly (maybe just a small preview of it), but instead refer the reader back to the node of the content owner. This would allow the content owner full control over who sees their content rather than exposing it in the feed (which could otherwise be republished without the owner’s consent).

WebSub is a deceptively simple push based publishing protocol maintained by the W3C. It enables a node to subscribe to another node and then get updates when that other node gets new content. It includes cryptographic securities to ensure identity of the publisher via a public / private key system. The one innovation that ATProto does make is to create a DID that is basically just a light wrapper around cryptographic primitives. A WebSub implementation could do it better though, because ATProto has no decentralized way of updating followers if you change domains. This would be trivial for a WebSub node.

Sometimes you might want better control over who can access your content. This is where OAuth comes in. OAuth is a way of establishing identity from a trusted identity provider and is maintained by an international community for internet standards, the IETF. Using OAuth, you could have your node authenticate the identity of visitors and assign them different roles. Based on these roles you would then give them access to various levels of content and interaction.

This would create a simple, efficient, and direct way of creating a decentralized social network using only open protocols.

What Could be Improved

Those open protocols I mentioned are enough to get something working, but there are a couple missing components to really finish the puzzle. One is an extension to Atom to make it aware of social interactions. Next is a discovery mechanism, and last is a feed reader to bring it all together.

Atom doesn’t inherently know about the social relationships between various forms of content, so we could create an extension that does. This would add fields to feed items that inform the consumer whether content is a base post, a repost, a response or comment, or a reaction (a “like”). Atom already supports extensions, so creating a new one wouldn’t be particularly revolutionary. If it became popular enough it would probably be standardized by the W3C, just like RSS was made into Atom itself.

The current setup is lacking a discovery system, but that doesn’t mean there isn’t a simple solution! Many podcast apps already rely on a central index or store to discover podcast feeds. We could do exactly the same thing for our WebSub nodes. This means that the content owner still hosts and exposes all their data themselves, but we have a simple and streamlined way for communities to form. There doesn’t have to be a single index, and creating one would be straightforward if you found the existing offerings to be lacking.

Lastly, we would need a feed reader. This is an end application and user experience that ties it all together. It would pull content from the user’s subscriptions (via their WebSub node) and expose an interface to publish new content to their node (which would get pushed out to their followers via WebSub). One could easily implement a Twitter (or Bluesky, or Mastodon) like experience for this.

The Real Work

The REAL problem with every decentralized web project that is NOT being address is the ability for users to EASILY set up and host their own nodes in the network. Anyone who could do this would have an immense opportunity to change the world (hopefully for the better. Don’t be another Meta or Google. Please. C’mon. Seek help). To do this you’d need to bring together a couple of pieces, the hardware and the setup experience.

The hardware is fairly straightforward. At the simplest, you could repackage a Raspberry Pi with a pre loaded image and distribute it to your customers. A slightly more refined version might integrate the node into a router or network box that a customer would easily accept, as most people already have routers or modems sitting around in their houses.

The software to support a seamless setup experience would be more complicated. You would need to create a wizard like flow that coordinates the setup of the various components, the data store, the websub node, oauth use, etc. In addition to this, you would want to somehow get the user to open and forward the correct ports, and help them set up a domain and DNS records. I don’t think this is impossible. Companies like Cloudflare provide CLI tools that could be integrated into scripts to accomplish these tasks. There are router protocols that allow for hosted applications to modify port configurations without full access to the router’s settings.

It would be a challenge still, which is where the opportunity to create a great experience for users that “just works” could bring immense growth.

ATProto Ain’t It

ATProto was created by a private corporation, and is controlled by them. It exists to serve the needs of its share holders and to fulfill the reasons why it was created. Yes, I know it’s a “public benefit corp” but that just means there’s a recourse for the public to bring lawsuits against them if they turn abusive. It doesn’t change the fundamental position that a corporation’s job is to create PROFIT, not user value.

A system built on open standards gives the user / content owner more agency. If the software being used to support their node somehow becomes unsuitable, other implementations of the same protocols can support the same functionality. By designing to open protocols that are maintained by fundamentally non-profit based organizations prevents users from being exploited. The purpose of the protocols (to create an open web) and the needs of the users (a reliable, replaceable, and maintainable system) are aligned.

ATProto also makes some weird choices for its data stores. For example, any “subscriber” (downstream node) has to crawl the publisher for new content. That’s weird. A push based system like WebSub gets the job done much more simply. Also, we don’t need a new data store protocol, Atom can represent any feed based data regardless of how it’s stored.

ATProto’s DID system IS kind of useful. It allows subscribers to know that when a publisher changes domains, that it’s still the same publisher. But ATProto doesn’t have any way to NOTIFY subscribers about those domain changes outside of a centralized app! Using our imagined WebSub system, a domain change could be published to subscribers along with a signature that ensures them that it’s coming from the owner of the right keys (which is ultimately all a DID is, a wrapper around cryptographic primitives).

The systems I have described and the work that needs to be done to get there are the way to create a decentralized and truly open web. We don’t need a new protocol governed by a private corporation. We have the protocols defined by open internet workgroups. What we NEED is hard work to provide the products and services that allow every day people to take advantage of them.