📄️ The AT Protocol
The AT Protocol (Authenticated Transfer Protocol, or atproto) is a standard for public conversation and an open-source framework for building social apps.
📄️ Federation Architecture
The AT Protocol is made up of a bunch of pieces that stack together. Federation means that anyone can run the parts that make up the AT Protocol themselves, such as their own server.
📄️ Links, mentions, and rich text
Posts in Bluesky use rich text to handle links, mentions, and other kinds of decorated text.
📄️ Rate Limits
Rate limits help service providers keep the network secure. For example, by limiting the number of requests a user or bot can make in a given time period, it prevents bad actors from brute-forcing certain requests and helps us limit spammy behavior.
📄️ Labels and moderation
Moderation in Bluesky consists of multiple, stackable systems, including:
📄️ Posts
This is an in-depth dive into how creating a post works on Bluesky. We'll use Python below, without a SDK, so you can see how it works behind the scenes.
📄️ Timestamps
Bluesky is a distributed network, which means clocks can skew and time is relative. Furthermore, tricksters might lie about timestamps in app clients or at the PDS instance level. To sort all of this out, we have a few simple guidelines for working with timestamps.
📄️ Firehose
One of the core primitives of the AT Protocol that underlies Bluesky is the
📄️ Resolving Identities
Identities in the Bluesky network consist of multiple parts:
📄️ Custom Schemas
The AT Protocol, and specifically Lexicon, provides a toolkit for creating decentralization social applications. Lexicon is meant to be a social coordination tool. It's an explicit way to announce the schema that some data adheres to and compare it against the schemas that your application understands.
📄️ Backfilling the Network
Backfilling is the process of syncing all the data in the network from scratch.
📄️ Read-After-Write
A user may take some action (such as updating their profile), rapidly refresh the view, and find that their recent change is not immediately reflected in the updated response.
📄️ Service Auth
There are currently two "types" of auth supported in the atproto network: client-server auth and service-to-service auth.
📄️ PDS Entryway
Bluesky runs many PDSs. Each PDS runs as a completely separate service in the network with its own identity. They federate with the rest of the network in the exact same manner that a non-Bluesky PDS would. These PDSs have hostnames such as morel.us-east.host.bsky.network.
📄️ oEmbed and Post Embed Widget
Bluesky posts can be embedded in other websites a couple different ways. For a non-technical guide on how to embed Bluesky posts on other websites, read here.
📄️ Action Intent Links
Authors, websites, and apps can use action intent links to implement "Share on Bluesky" buttons, or similar in-app actions. Logged-in users will be directed to the corresponding action view in the Bluesky app (mobile or web app) with context pre-populated. Logged-out users will be prompted to sign-in or create an account first. Following the link does not automatically result in the action; the logged-in user still needs to confirm the action.
📄️ OAuth Client Implementation
This is a guide to implementing atproto OAuth clients "The Hard Way." Optimistically, most developers will have an SDK available for their programming language which supports OAuth, and they can simply refer to SDK documentation. This guide is intended for early adopters, SDK maintainers, or developers with more sophisticated OAuth needs. It is agnostic to whether developers are building clients to work the the app.bsky microblogging Lexicons, or implementing novel application Lexicons.
📄️ API Hosts and Auth
Lexicon API definitions do not always indicate which network services implement the endpoint, and whether auth is required when making HTTP requests. This guide describes the most common API request patterns, and lists the specific hostnames for Bluesky-operated services.