Atlasemoji
Learn
Connected systems & AI · 30 of 40

AT Protocol: identity, repositories, records, and services

Understand the pieces behind Bluesky-style AT Protocol applications instead of treating a handle as the whole identity.

Why this matters

AT Protocol separates identity, hosted repositories, schemas, relays, and application views. That separation makes it a useful example of a federated system where the same records can support different applications and services.

Learn it

AT Protocol uses decentralized identifiers (DIDs) as stable account identities and human-readable handles as names that can change. User data is stored in signed repositories of records. Personal Data Servers host account data; relays aggregate repository updates; App Views provide application-oriented indexes and views. Lexicons define schemas and API behavior so different implementations can understand the same records.

Work through an example

A post record can declare its Lexicon type, text, and creation time. The record lives in a user's repository; an application view can index it for search or feeds.

A small AT Protocol record shape
{
  "$type": "app.bsky.feed.post",
  "text": "Observation received",
  "createdAt": "2026-09-30T17:00:00Z"
}

Practice

  1. 1Separate DID, handle, PDS, repository, relay, and App View in the protocol architecture.
  2. 2Read the sample and identify the record type and application data.
  3. 3Explain why a handle can change without changing the underlying DID identity.

What to watch for

Do not treat a DID, handle, and PDS hostname as interchangeable identifiers. They serve different roles.

Where this takes you

This prepares users to understand Bluesky/ATProto connections in Atlas Crossband and other applications built on the protocol.

    AT Protocol: identity, repositories, records, and services | Atlasemoji Learning | Atlasemoji