FAQ

Frequently Asked Questions about the Authenticated Transfer Protocol (AT Proto). For FAQ about Bluesky, visit here.

Is the AT Protocol a blockchain?

No. The AT Protocol is a federated protocol. It's not a blockchain nor does it use a blockchain.

Why not use ActivityPub?

ActivityPub is a federated social networking technology popularized by Mastodon.

Account portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.

Another major reason is scalability. ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual nodes to be flooded with traffic and generally struggles to provide global views of activity. The AT Protocol uses aggregating applications to merge activity from the users' hosts, reducing the overall traffic and dramatically reducing the load on individual hosts.

Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP's double-@ email usernames, and the goal of having large scale search and algorithmic feeds.

Why create Lexicon instead of using JSON-LD or RDF?

Atproto exchanges data and RPC commands across organizations. For the data and RPC to be useful, the software needs to correctly handle schemas created by separate teams. This is the purpose of Lexicon.

We want engineers to feel comfortable using and creating new schemas, and we want developers to enjoy the DX of the system. Lexicon helps us produce strongly typed APIs which are extremely familiar to developers and which provides a variety of runtime correctness checks.

RDF is intended for extremely general cases in which the systems share very little infrastructure. It's conceptually elegant but difficult to use, often adding a lot of syntax which devs don't understand. JSON-LD simplifies the task of consuming RDF vocabularies, but it does so by hiding the underlying concepts, not by making RDF more legible.

We looked very closely at using RDF but just didn't love the developer experience (DX) or the tooling it offered.

What is “XRPC,” and why not use ___?

XRPC is HTTP with some added conventions. We're aiming to retire the term "XRPC" and just refer to it as the ATProto usage of HTTP.

XRPC uses Lexicon to describe HTTP calls and maps them to /xrpc/{methodId}. For example, this API call:

await api.com.atproto.repo.listRecords({
  user: 'alice.com',
  collection: 'app.bsky.feed.post'
})

...maps to:

GET /xrpc/com.atproto.repo.listRecords
  ?user=alice.com
  &collection=app.bsky.feed.post

Lexicon establishes a shared method id (com.atproto.repo.listRecords) and the expected query params, input body, and output body. By using Lexicon we get runtime checks on the inputs and outputs of the call, and can generate typed code like the API call example above.