--- title: Apps, AppViews, and the firehose description: How the same data gets read by multiple Atmosphere apps. Why Sifa shows you a different view of your activity than Bluesky does. --- The Atmosphere is **one network of data, many apps reading it**. [Bluesky](https://bsky.app), Sifa, [Tangled](https://tangled.org), [Leaflet](https://leaflet.pub), 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's 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; reading from one means you don't have to keep a connection open to every PDS yourself. The relay doesn't decide what's important. It just rebroadcasts. Bluesky operates a main relay at `bsky.network`, and a lighter JSON-formatted variant called Jetstream is widely used by smaller AppViews that don't want to handle the binary protocol the main relay speaks. ## 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, every page view would have to 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 disappears from Sifa within seconds, because the relay broadcasts the deletion and Sifa's AppView removes 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 do things (post a message, edit your profile, give an endorsement). Writes go to your provider, not to the AppView. 3. **Authenticate** as you with your provider when writing. A single app can be specialised: Bluesky focuses on microblog posts, Sifa focuses 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](/docs/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](https://pdsls.dev) reads directly from your provider and shows every record. ## Why this design matters You've probably spotted the pattern. Twitter, LinkedIn, 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 your own server, if you self-host). Apps read your data and render it. Don't like how an app renders? Switch to another app, your data is unchanged. App shuts down? Your data is still there. 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 don't lose your inbox. ## Want to go deeper - [Your data on a provider](/docs/your-data-on-a-provider): what records look like, where they live. - [DIDs, handles, and providers](/docs/dids-handles-providers): the parts of your identity. - [Activity feed](/docs/activity-feed): exactly which records Sifa shows on your profile. - [Atom feeds](/docs/atom-feeds): another way to consume your Sifa activity, with no Atmosphere account needed. For a deeper developer-facing tour of every layer (including labellers, feed generators, and the PLC directory), Kuba Suder's [Introduction to AT Protocol](https://mackuba.eu/2025/08/20/introduction-to-atproto/) is the canonical long read.