- ATProto Core Elements:
- Record: Stores actions like posts and follows as JSON objects. Each user can only modify their own Records.
- Blob: Binary files such as images and videos.
- Lexicon: Defines Record structure (schema). Bluesky-specific ones use
app.bsky.*
, common ones usecom.atproto.*
. - DID: Unique account identifier. Permanent, while handles can change freely.
- Handle: Domain format (@user.com). Mapped to DID, so relationships are maintained even when changed.
- AT URI: Uniquely refers to Records in the format
at://<DID>/<lexicon>/<rkey>
. - Repo: Personal storage containing all user data (Records, Blobs).
- Network Server Structure:
- PDS (Personal Data Server): Stores each user's original data. Migration between PDSs is possible.
- Relay: Combines event streams (firehose) from multiple PDSs to provide a complete network stream.
- Jetstream: Lightweight JSON version of Relay output.
- AppView: API server used by clients. Provides processed data like follower counts, likes, search, timelines. (Bluesky uses a large-scale ScyllaDB version)
- CDN: Optimizes image and video delivery.
- Additional Components:
- Labeller: Third-party moderation service. Can apply labels to block or warn about content/users.
- Feed Generator: Service that provides custom feeds created by anyone. (Keywords, algorithm-based recommendations, etc.)
- Client App: Web/mobile clients like bsky.app. Loads data through PDS and AppView.
- DM: Currently a temporary centralized service (chat.bsky.*), with plans to apply E2E encryption standards long-term.
- Operational Flow:
- User posts/follows → Record stored in PDS
- PDS → Event forwarded to Relay
- Relay → Data transferred and processed by AppView
- Client apps display timelines and threads received from AppView
- Feed Generators and Labellers also receive Relay streams to add functionality