Oct 31, 2026 · @Steve Emanuelson

Who holds your data?

On the AT Protocol, your data lives in a repository you control, and apps read and write to it instead of keeping it for themselves.

That flips the arrangement most of us have accepted for twenty years. You sign up for an app, your posts, reviews, lists and likes, all sit in that company's database. If the app shuts down, changes its rules, or simply stops being the place you want to be, your history stays behind. Export tools, if they exist, hand you a zip file that no other service knows how to read.

The AT Protocol (ATProto) is the open protocol behind Bluesky, and the growing collection of apps built on it is called the Atmosphere. Its core idea is simple: every account comes with its own Personal Data Server, and every app you use writes into it. This article walks through how that storage works, using a Bluesky post as the first example and film logging as the second.

Your PDS: one repository, many collections

A Personal Data Server (PDS) hosts your account's repository: a signed store of everything you publish, organized into collections of records.

A few terms make the rest of this article easier to follow:

  • DID — your permanent account identifier, such as did:plc:44ybard66vv44zksje25o7dz. It never changes, even if you switch servers.

  • Handle — the human-friendly name, such as alice.bsky.social or your own domain. Handles can change; the DID underneath stays put.

  • Repository — the store of all your public data. Every change is a signed commit, so anyone reading your data can verify it came from you.

  • Collection — a bucket of records of one type, named with a reverse-DNS identifier called an NSID (for example app.bsky.feed.post).

  • Record — one piece of data: a post, a like, a follow, a film review. Each has a record key (rkey) that is unique within its collection.

  • Lexicon — the schema that defines what a record in a collection must contain. Whoever controls the domain in the NSID publishes the Lexicon.

Put together, every record has an address of the form at://<DID>/<collection>/<rkey>. Bluesky's own server is only one PDS host among many. You can move to another provider, or run your own, and take the whole repository with you.

Example 1: Post to Bluesky

When you post on Bluesky, the app writes a record into the app.bsky.feed.post collection of your own repository.

The record itself is plain JSON. A simple post looks like this:

{
  "$type": "app.bsky.feed.post",
  "text": "Rewatched The Shawshank Redemption tonight. Still the best ending in movies.",
  "langs": ["en"],
  "createdAt": "2026-10-31T11:55:00.000Z"
}

Its address combines your DID, the collection, and a record key generated from the timestamp:

at://did:plc:44ybard66vv44zksje25o7dz/app.bsky.feed.post/3m7xq2abcd22k

The post is only one kind of record. The rest of your Bluesky activity sits beside it in sibling collections:

What you did | Collection

Wrote a post or reply | app.bsky.feed.post

Liked a post | app.bsky.feed.like

Reposted | app.bsky.feed.repost

Followed someone | app.bsky.graph.follow

Set your name, bio, avatar | app.bsky.actor.profile (one record, key self)

Because public records are public, you can see this for yourself. Asking your PDS for com.atproto.repo.listRecords with your handle and collection=app.bsky.feed.post returns your posts, no login required. Tools such as pdsls.dev let you browse any account's collections in a web browser.

The important part: Bluesky the company runs an app that reads these records from across the network and builds timelines from them. It does not own the post. The post lives in your repository, signed by your account.

Example 2: logging films, Letterboxd vs. the Atmosphere

On Letterboxd your movie diary lives in Letterboxd's database; on an Atmosphere app like Popfeed, the same review is a record in your own repository.

In the silo model each app keeps your data; in the Atmosphere, apps read and write one repository you control.

Letterboxd is a good illustration of the familiar model, and a well-loved one. Years of diary entries, star ratings, reviews and lists build up inside one company's servers. You can export a CSV, but no other service treats that file as a live, shared part of your identity. Your film history only works where Letterboxd says it works.

Popfeed does the same job for films, shows, books, games and music, but signs you in with your Atmosphere account and writes into your PDS. It can even import your Letterboxd, Goodreads and StoryGraph data, turning an old export into records you hold. Its data sits in collections under the social.popfeed namespace:

What you did | Collection

Rated or reviewed a film | social.popfeed.feed.review

Made a list (watched, watchlist, rankings) | social.popfeed.feed.list

Added a film to a list | social.popfeed.feed.listItem

Set your favorites and bio | social.popfeed.actor.profile

A review record, simplified, looks something like this:

{
  "$type": "social.popfeed.feed.review",
  "title": "The Shawshank Redemption",
  "rating": 10,
  "text": "Patient, hopeful, and worth every rewatch.",
  "containsSpoilers": false,
  "isRevisit": true,
  "createdAt": "2026-10-31T11:55:00.000Z"
}

It sits right next to your Bluesky posts, in the same repository, under the same DID:

at://did:plc:44ybard66vv44zksje25o7dz/app.bsky.feed.post/3m7xq2abcd22k
at://did:plc:44ybard66vv44zksje25o7dz/social.popfeed.feed.review/3m7xq3efgh22k

This is where shared formats pay off. Because the records are public and the shape is known, other apps can build on them without asking Popfeed. Book apps such as BookHive already write Popfeed's list format for reading shelves, and newer projects like Papertrail read both BookHive and Popfeed reviews. A bridge from NeoDB even carries Popfeed reviews into the Fediverse. None of that required a partnership deal; it only required the data to live with the user.

Why this matters

When apps are views onto data you hold, leaving an app no longer means leaving your history behind.

  • Your history survives the app. If a film app shuts down or changes direction, your reviews stay in your repository. A new app can read them on day one.

  • One identity everywhere. The same account signs you into Bluesky, Popfeed, a blogging app or an events app. Your handle can be a domain you own.

  • Interoperability without permission. Apps that agree on a Lexicon can read each other's records directly. No API keys, no business-development deal, no scraping.

  • Credible exit. You can switch apps, or move your whole repository to another PDS host, without losing followers, posts or reviews. Apps have to keep earning your use.

  • Small apps can matter. A new app does not start from an empty database. It can show your existing social graph and data straight away, so niche tools for small communities become viable.

  • Competition on experience. Apps cooperate on the data layer and compete on design, curation and moderation, rather than on how well they lock you in.

Joe Basser, borrowing Dan Abramov's phrase, calls the result an "everything ecosystem" rather than an everything app: many teams building different views onto one shared, user-held substrate.

What to keep in mind

The model is real and working today, but it comes with trade-offs worth stating plainly.

  • Records are public. Everything in your repository can be read by anyone. Private data support is still being developed, so ATProto apps today suit things you are happy to publish, like reviews and posts.

  • Data is portable; services are not. Your PDS holds the records, but the timelines, search and film catalogues are built by each app's own servers. If an app disappears, you keep the data, but someone has to build a new app to show it.

  • Formats can change. Lexicons are defined by whoever owns the namespace. Popfeed itself moved from app.popsky.* to social.popfeed.*, migrating users' records along the way. Community efforts such as Lexicon.community aim to agree on shared formats for common things.

  • The ecosystem is young. Bluesky dominates in size, and many Atmosphere apps are small, independent projects. Some still have rough edges, such as limited support for self-hosted PDSes.

The takeaway

On ATProto, your account is a repository and apps are guests in it.

A Bluesky post lands in app.bsky.feed.post. A film review from Popfeed lands in social.popfeed.feed.review. Both sit side by side under one identity, in a server you can choose or run yourself. That one shift, from data held by apps to data held by people, is what makes the rest possible: switching apps freely, new tools that start with your history, and an ecosystem where apps win by being good rather than by being hard to leave.

If you already have a Bluesky account, you are in the Atmosphere. Try opening your handle in a repository browser like pdsls.dev and look at the collections you already own.

Sources