Apps, AppViews, and the firehose

The Atmosphere is one network of data, many apps reading it. Bluesky, Sifa ID, Tangled, Leaflet, and the rest all read from the same pool of records and render them however they like.

Four pieces make this work, in order: providers publish data, relays aggregate it, AppViews index the aggregate, and apps render what is in the index.

Providers publish

Your provider (your PDS) is the source of truth for everything you write. Every record you create goes to your provider first. Your provider then exposes a firehose: a real-time stream of every record created or modified on it.

Across the whole network there are thousands of providers, each with its own firehose. Asking each one individually for new records would be impossibly slow for an app trying to surface your timeline.

Relays aggregate the firehose

A relay subscribes to many PDS firehoses at once and merges them into a single combined stream of everything happening on the network. Anyone can run a relay. If you read from one, you keep no connection to each separate PDS.

The relay does not decide what is important. It just rebroadcasts. Bluesky operates a main relay at bsky.network. A lighter JSON variant called Jetstream serves smaller AppViews. Those AppViews prefer JSON over the binary protocol of the main relay.

AppViews index for an audience

Reading the firehose stream and answering questions like "what did Alice post this week?" needs a database. So apps almost always have an AppView: a service that reads the relay's stream and indexes the records into a database tuned to the questions that app needs to answer.

Sifa runs its own AppView at sifa.id. It indexes the records it cares about: your id.sifa.* profile records, the app.bsky.* activity that shows up on your profile, the forum.barazo.* posts that flow through Sifa's community feed.

The AppView is what makes your profile load fast. Without it, each page view would ask hundreds of providers for the latest data.

One thing to remember: the AppView is a cache, not the source of truth. Your records live on your provider. The AppView is Sifa's index of them. Delete a record from your provider, and it leaves Sifa within seconds. The relay broadcasts the deletion, and the Sifa AppView drops it from the index.

Apps render

An app is what you use. The Bluesky web app, the Sifa web app, a third-party desktop client: all apps.

Apps usually do three things:

1. Read from an AppView to render their UI.
2. Write records on your behalf when you act: a new message, a profile edit, an endorsement. Every write goes to your provider, not to the AppView.
3. Authenticate as you with your provider for every write.

Each app can specialise. Bluesky focuses on microblog posts, Sifa on professional identity, Tangled on Git repositories. Each app reads the records that matter to it and ignores the rest.

Why Sifa and Bluesky show different views

Same records, two different apps, two different presentations:

• Bluesky shows everything (posts, likes, reposts, follows) because Bluesky is a social timeline.
• Sifa shows only the work you create (articles, repos, RSVPs, reviews) because Sifa is a professional profile. See Activity feed for the exact allow-list.

Neither view is the "real" one. Both are honest renderings of the same records, filtered for different purposes. Want to see everything on your account, unfiltered? pdsls.dev reads directly from your provider and shows every record.

Splitting the data from the app

You probably see the pattern. Twitter, LinkedIn and Facebook each store your data, decide how to display it, and charge advertisers for access. The data and the app are the same company.

The Atmosphere splits them apart. Your data lives on your provider, or on your own server if you self-host. Apps read your data and render it.

Do you dislike how one app renders it? Switch to another app, and your data stays as it is. If an app shuts down, your data stays too.

Same shape as email: your inbox lives on your mail server, your mail client just reads it. Switch from Apple Mail to Thunderbird and you do not lose your inbox.

Want to go deeper

• Your data on a provider: what records look like, where they live.
• DIDs, usernames, and providers: the parts of your identity.
• Activity feed: exactly which records Sifa shows on your profile.
• Atom feeds: another way to consume your Sifa activity, with no Atmosphere account needed.

Kuba Suder's Introduction to AT Protocol is the canonical long read. It tours every layer, and it covers labellers, feed generators, and the PLC directory.