ActivityPub vs ATproto comes down to architecture: ActivityPub federates independent servers that message each other, while the AT Protocol splits accounts, relays and app views into layers, with portable identity built in.
Both power open social networks, and both sit within the wider landscape of any community platform that wants users to own their data.
How ActivityPub works
ActivityPub is a W3C standard. According to Wikipedia’s ActivityPub entry, it was first published as a W3C Recommendation in January 2018 by the Social Web Working Group. Further development later moved to the Social Web Community Group. The protocol offers a client-to-server API for creating and modifying content, plus a federated server-to-server protocol for delivering notifications and content to other servers.
Its content format is ActivityStreams 2.0, which itself uses JSON-LD. The three main data types are Objects, Activities and Actors. Actors represent an individual, a group, an application or a service, and every actor has an inbox and an outbox. To publish something, such as a like, a user creates an activity and posts it to their outbox. The server then delivers it by a POST request to the inboxes named in the activity.
ActivityPub is the defining standard of the Fediverse, a network of independently managed instances. Mastodon, Lemmy, PeerTube, Pixelfed and many others speak it. Each server hosts its own users and is the home of their data, so an account normally lives and dies with its server.
ActivityPub implementations commonly pair the protocol with discovery through webfinger, which lets one server look up an account on another. WebFinger is defined in RFC 7033, published in September 2013, and returns a JSON Resource Descriptor for a requested resource. Wikipedia notes that the older OStatus protocol also used WebFinger alongside Atom, Salmon and WebSub, which made it hard to implement in new software.
How the AT Protocol works
The AT Protocol (Authenticated Transfer Protocol) was developed by Bluesky Social PBC. The Wikipedia entry on the AT Protocol lists its introduction as October 18, 2022. The company has said it may seek to standardize additional specifications through the IETF, depending on the outcome of current efforts. That contrasts with ActivityPub, which already has a W3C Recommendation.
The official protocol overview says the three core services in the network are Personal Data Servers (PDS), Relays and App Views. Relays collect data updates from many servers into a single firehose. Feeds, labelers and search indices can be provided by independent third parties. Repository data is synchronized between servers over standard web technologies, HTTP and WebSockets.
Applications interoperate by reading and writing user records that follow published Lexicon schemas, according to the AT Protocol specification. Developers extend the network by publishing new Lexicon schemas under independent NSID hierarchies, and network APIs are described with those schemas through XRPC.
Wikipedia reports that the protocol prioritizes data portability, letting users back up and migrate repositories and media without data loss, even in the event of an adversarial PDS. Because AppViews all work from the same firehose data, users can switch between them while keeping posts, follows and likes.
Identity: handles, DIDs and portability
Identity is the sharpest technical difference. On ActivityPub, an account is generally an actor URL on one server, so moving means a migration that the server software must support. On the AT Protocol, users have permanent decentralized identifiers (DIDs), and a configurable domain name acts as a human-readable handle.
The DID specification states that atproto currently supports two DID methods. One is did:plc, a self-authenticating method developed specifically for atproto. The other is did:web, a W3C community draft based on HTTPS and DNS, which is supported to provide an independent alternative. The same page warns that did:web is tied to the domain name used and offers no mechanism for migration or recovery if control of the domain is lost.
Critics have taken aim at did:plc. Wikipedia notes it has been described as a single point of failure because its current implementation relies on a single registry hosted by Bluesky Social. That is a live tradeoff: portability for users, but a central component for the network.
Handles follow DNS rules. The handle specification says a handle is a mutable, human-friendly username in the form of a DNS hostname. It may contain only ASCII characters and be at most 253 characters long, and each segment must be between 1 and 63 characters. Resolution to a DID works through either a TXT DNS record or an HTTPS /.well-known/ path.
ActivityPub vs ATproto side by side
| Aspect | ActivityPub | AT Protocol |
|---|---|---|
| Steward | W3C Recommendation | Bluesky Social PBC |
| Data format | ActivityStreams 2.0 / JSON-LD | Lexicon schemas, XRPC APIs |
| Delivery | Server-to-server inbox and outbox POSTs | Repositories synced through relays into a firehose |
| Account identity | Actor on a home server | DID plus DNS-based handle |
| Core roles | Instances | PDS, Relays, App Views |
Table details draw on the ActivityPub entry on Wikipedia and the official atproto overview.
Which tradeoffs matter in practice
ActivityPub’s strength is a mature standard and a broad software ecosystem. Wikipedia’s software table lists many projects, from microblogging to video hosting, that implement it. A team choosing a stack can therefore pick a server, a client and a content type, such as short posts, video or forums, from separate projects that still interoperate. Its weakness is that moderation, discovery and data ownership are tied to individual servers, and the behaviour of each implementation can vary.
The AT Protocol’s strength is separation of concerns. Hosting data, aggregating it and presenting it are different jobs, so a user can change hosts or feeds without losing a social graph. Wikipedia notes that the largest AppView is currently Bluesky, with others such as Blacksky and Frontpage also running on the network. The weakness is that the relay and did:plc infrastructure is more centralized in practice than the design suggests.
Neither protocol replaces the other. Choosing between them usually depends on what a project values: a standardized, widely implemented federation model, or a layered design where identity and data move freely between providers. Communities that want to run their own infrastructure may favour ActivityPub’s server-centric model, while developers building custom feeds or algorithms may prefer the AT Protocol’s open firehose. They also differ from chat-focused systems; a comparison of matrix vs discord covers a different problem, real-time messaging, rather than public social feeds. Bridges between ActivityPub and atproto exist as separate projects, but compatibility is not part of either specification.
Frequently asked questions
Is the AT Protocol an open standard?
Its specifications are published openly at atproto.com. Wikipedia states the developer has said it may seek to standardize additional specifications through the IETF, so it is not a finished standards-body process.
Can ActivityPub and AT Protocol users talk to each other directly?
Not natively. The protocols use different data models and identity systems. Any connection depends on third-party bridges.
Which protocol makes switching servers easier?
The AT Protocol is designed for it, since DIDs and repositories are portable. ActivityPub account migration depends on the server software in use.
What is a handle in the AT Protocol?
A handle is a mutable username in the form of a DNS hostname, resolved to a permanent DID by a DNS TXT record or an HTTPS well-known path.
