TL;DR
Atproto is big-world, open social. Users publish JSON records into repositories. The changestreams of those records then sync across the network to drive applications.
We recommend these fantastic articles by community member Dan Abramov:
- Open Social - The protocol is the API.
- Where it's at:// - From handles to hosting.
- A Social Filesystem - Formats over apps.
Core primitives
- User repos. The public per-user databases.
- User handles. Usernames, which are DNS records. Our account is @atproto.com.
- User DIDs. The permanent IDs of users.
Data models
- Records. JSON, categorized into collections.
- Blobs. The images and videos.
- Lexicon. The schema language.
- Lexicon RPC (XRPC). It's HTTPS but with the routes defined by Lexicons.
The stack
There are different kinds of services which you can self-host:
- Personal Data Servers (PDS). They host user accounts.
- Relays. They collect and rebroadcast user write events.
- Applications. They aggregate user data to produce app experiences.
- Labelers. Publish moderation decisions as label metadata.
Making it happen
Let's assume you're building an application. Your users will sign in with OAuth, which hands your application the address of their PDS. Your application then reads & writes records by contacting their PDS.
To listen for activity across the network, you sync from relays. You could sync directly from the users' PDSes, but it's more convenient to use the relays. Since all data is signed, you can confirm the relay's stream is accurate.
The Lexicons help identify the data being published on the network. You use them to validate data as you read it, just like you validate incoming HTTP requests.
Finally, you handle moderation by subscribing to (or running) labelers which receive user reports and publish labels on user content.
Deeper reads
We also recommend these deep-dive articles by the team:
- Atproto for distributed systems engineers. An explainer for backend thinkers.
- The Atproto Ethos. The principles that underpin the design of atproto.