Feed generators are specialized services within the AT Protocol that creates custom algorithmic timelines for users, meant to enable content curation approaches beyond the standard reverse-chronological feeds. They can cater to topic-based, interest-based, or otherwise algorithmically curated content experiences.
Feed generators provide alternative ways to discover and consume content across the ATmosphere. While the AppView provides a basic chronological timeline of posts from followed accounts, feed generators can implement more sophisticated algorithms that select and rank content based o various criteria. Feed generators and labelers represent the "opinionated" layer of the AT Protocol ecosystem.
Feed generators consume the firehose from relays and apply their custom algorithms to select posts that match their specific curation goals. When a user requests a feed, the feed generator returks a "skeleton" of post preferences, which are then hydrated into full content by the user's Personal Data Server (PDS) or AppView.
From a user experience, feed generators generally appear as feeds within client applications, which users can subscribe to. Users can discover feeds through directories, recommendations, or direct links, subscribing to feeds which best serve their interests. The aim of this approach is to give users agency in selecting algorithmic experiences that best serve their interests, rather than being subject to a unitary platform-defined algorithms. If users become dissatisfied with a particular feed, they can ideally unsubscribe and choose alternatives.
The feed generator architecture follows a simple design pattern meant to create a clean division of responsibilities between content selection and content delivery.
Each feed algorithm is declared as a record in the repository of its creator, typically using the app.bsky.feed.generator collection. This declaration includes metadata about the feed (e.g. name, description, avatar) and points to the service that hosts the algorithm. The feed generator service itself is identified by a decentralized identifier (DID) to allow for secure communication and authentication.
When a user requests a feed, their PDS resolves the feed's AT URI to find the feed generator's service endpoint. The PDS then sends a getFeedSkeleton to this endpoint.
Feed generators authenticate a user's identity with a JWT signed by the user's signing key. The feed generator then returns a "skeleton" of the feed - a list of post URIs with optional ranking signals or metadata. The user's PDS hydrates this skeleton with full post content, user information, and engagement metrics before returning it to the client application.