An AppView is an AT Protocol service that turns raw repository records into application-ready views. It can index posts, build threads, count likes, resolve relationships and provide feed-oriented APIs without being the authoritative owner of the underlying user data.
Turning signed records into a usable application
AT Protocol repositories are deliberately simple signed data stores. They do not themselves answer every question a social client needs, such as 'show this thread with reply counts, author profiles and viewer-specific relationship state'. An AppView subscribes to network data, commonly through a relay, indexes the records and materialises those richer views. Bluesky's app.bsky services are one example, but the architecture allows different AppViews to interpret or present compatible underlying records in different ways.
Why hosting and presentation are separate
This is one of the protocol's most important separations. Hosting a user's signed records and presenting a social application are different jobs. A new client can potentially build alternative ranking, moderation or interface behaviour without becoming the custodian of every user's authoritative repository. It also explains why moving a PDS does not mean recreating all search and feed infrastructure locally.
Protocol decentralisation versus service concentration
An AppView is still a service with policies, indexes and availability constraints. If most users rely on a single AppView, practical power can remain concentrated even though data hosting is distributed. AppViews also need to understand the Lexicons they index, so novel record types do not automatically become visible in every existing application.
Related reading
- What Is a PDS in AT Protocol? Personal Data Servers Explained
- What Is an AT Protocol Lexicon? How Bluesky Defines New Types of Data