AppView

An AppView in the AT Protocol is a specialized service that processes and indexes network data to provide application-specific functionality. It sits at the top of the layer of the protocol's architecture, consuming relay firehoses and transforming raw repository data into useful, queryable information tailored to specific social applications.

Core Functions

The AppView serves as the "intelligence" layer of the AT Protocol ecosystem, performing several indispensible functions that enable rich social experiences.

Record Processing and Indexing

The AppView consumes the firehose from a relay and processes records relevant to its specific application domain. For example, for the Bluesky social app, this means handling records in the com.atproto and app.bsky lexicon namespaces. The service validates each record against its schema, ensuring data integrity before indexing.

As it processes records, the AppView builds sophisticated indices and aggregations. It counts likes on posts, collates threads of replies, maintains follower relationships, and constructs personalized timelines. These computations transform the raw repository data into the social graph and content structures that users expect from a social network.

The AppView tracks the most recent processed revision for each repository and handles record and account-level deletions appropriately. It also enforces application-level constraints and deduplicates graph relationships when necessary, such as preventing duplicate follows or likes.

Media Distribution

When records reference media files such as images or videos, the App View fetches these blobs from the original Personal Data Server (PDS), processes them as needed, and makes them available through a content delivery network (CDN). This might include resizing images to reduce the file size or generating thumbnails for videos.

Moderation Enforcement

Moderation controls comprise one of the most important roles of an AppView. It applies both user-defined and platform-level moderation rules to the content it serves. For example, if one user has blocked another, the AppView ensures that interactions between these users are appropriately filtered from all views . Block relationships within the AT Protocol are public so that AppViews can process block relationships and properly enforce these boundaries.

AppViews also support infrastructure-level takedowns of content and accounts, often implementing labeling systems that consume data from labeller services to provide content warnings or filtering.

Query Interface

AppViews expose a web service API through which clients can query the processed and indexed data. Client applications don't access this API directly - instead, they query the user's PDS, which then proxies requests to an AppView. This architecture ma* intains the user's agency while leveraging the AppView's comprehensive indexing.

Personalization and User Data

Beyond public content indexing, AppViews often store and manage private user preferences and settings. This might include tracking notification state, facilitating push notifications to mobile devices, or storing mute lists that affect content filtering.

Some AppViews implement authentication systems to verify user identity for direct requests, either by verifying service authentication tokens proxied through PDSes or by implementing client OAuth for direct connections from applications.

Decentralization Benefits

The AT Protocol's architecture allows for multiple AppViews serving the same content to exist simultaneously, each potentially offering different features, moderation policies, or performance characteristics. If users are unhappy with the moderation rules or other aspects of one AppView, they can switch to an alternative that better aligns with their preferences.

This flexibility extends to developers as well. Different social applications built on the AT Protocol an create their own specialized AppViews that interpret and index repository records according to their specific needs, while still leveraging the same underlying PDS and relay infrastructure.

Technical Considerations

Running an AppView requires significant computational resources, as it must process the entire firehouse of network activity, maintain complex indices, and serve queries with low latency. The specific requirements depend on the application's complexity and network size.

AppViews typically implement sophisticated caching strategies, database optimization techniques, and distributed processing to handle the scale of a social network. They must also be resilient to network issues, data inconsistencies, and malformed records.

Further Reading

• What does an AppView implementation entail?