Bluesky released early documentation for the "AT Protocol" (atproto) a few weeks ago, and I've been noodling around with it. Technically, it strikes an appealing balance between rigid cryptographically-signed content-addressable storage on the one hand, and familiar web-friendly schemas and integrations on the other. But at an ecosystem level, there are already a bunch of existing open social media projects. Does atproto bring anything interesting to the table? How might it fit in compared to other similar protocols?
First, as quick background, atproto is a dweb social media protocol which aspires to replace Twitter as a centralized platform. Bluesky, the organization developing it, is a small company with history intertwingled with Jack Dorsey and Twitter itself. The folks there also have ties to more established dweb tech projects like IPFS, Scuttlebutt, and dat.
What sets atproto apart from other dweb and fediverse projects is that it is explicitly trying to support some of the “big world” features of Twitter. This means global discovery and “leaderboard” metrics (“likes”, “followers”), and also means “broadcast” content that gets rapidly replicated to millions (billions?) of users. It also supports, to some degree, the ability to redistribute and discuss pieces of content outside of their original context (“context collapse”).
I myself mostly dislike these properties for social media, but I do think they have positive social value in some cases. For example, short-form official announcements (eg, local weather warnings, flash flood alerts, public transit disruption), or short-form journalism (eg, as live blogging breaking events). I do not have a Twitter account, but some of the use cases that I personally still end up going there for today include local breaking news (what is that smoke cloud in my city, what is happening at a protest); seeing what “anybody” is saying about a project (eg, search by project name or domain name); checking if people or institutions are A Thing (what do they say in public feed, who is interacting with them); and generally what individual people or institutions are up to. These are all "big world" use cases that can't be met by the circle of folks a couple social hops from me.
It does feel to me that some these use-cases were well served by older web and indieweb tech, like (micro)blogs and RSS. Especially for the last case (“what are people up to”), which depending on the person may best be found on a homepage or blog. Maybe if social platforms were more open and had better sitemap tech then generic search engines could provide the big world features?
But many current dweb/fediverse projects try to specifically steer away from “big world” aggregations, and instead focus on “small world” in-community discussion. They do provide the technical ability to engage across communities and with the broader public. But I suspect many want to avoid rapid aggregation, leaderboards, and global discovery.
My take is that atproto should explicitly double-down on these use cases, because others are not. The project should also try to support existing (indie)web protocols like RSS and (possibly) ActivityPub. I don’t think they should directly try to support private messaging (leave that to Signal and Matrix, maybe with some identity/contact level interop), or forum-like small-world discussion with community-level norms (leave that to Discourse for web-index-able stuff, or SSB, or Mastodon).
Speaking of ActivityPub, I see two main contrasts against atproto. The first is that atproto specifies how user content should be canonically stored, while ActivityPub specifies event notifications between servers. An analogy is that ActivityPub is more like RSS (in which content may be truncated or otherwise non-canonical in an RSS feed) matter much), while atproto is more like a git repo (original content is transferred in canonical form; there is some awkwardness about large blobs/media). I think the atproto way makes it easier for an ecosystem to be interoperable in the long run, reduces the stress and obligations of hosting content on servers (because it is easy to backup and migrate), and empowers individual users. The other big contrast is full-strength account migration support in atproto, which works even without any participation by former hosting providers.
This last feature, building on decentralized identifiers (DIDs), is in my view the least mature and riskiest part of the currently proposed system. DID is a W3C specification, but really feels like it comes from the blockchain/web3 world. did:web does exist and should work fine, but itself is a big nothing burger because it does not enable the interesting account migration features that a true DID would. It should be possible to implement something like Certificate Transparency to do global-trusted and rapidly resolvable DIDs without wasteful proof-of-whatever, but that would require an effort and institution like Let’s Encrypt did for SSL certificates. It is unclear if or when that might actually happen. As it stands today DID has a pile of good intentions and standardization scaffolding, but in reality is just blockchain and vaporware.
As part of noodling around with the protocol, I wrote a simple partial command-line tool and personal data server (PDS), adeonsine. You can check out the minimal web interface at the examples pierre-manard.robocracy.org and voltaire.demo.adenosine.social.