Editing Feed generator

A '''Feed Generator''' in the [[AT Protocol]] is a specialized service that creates custom algorithmic timelines for users. These services enable diverse content curation approaches beyond the standard chronological or "following" feeds, allowing for 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 psots from accounts a user follows, feed generators can implement more sophisticated algorithms that select and rank content based on various criteria.

Similar to [[Labeler|labelers]], feed generators represent the "opinionated" layer of the AT Protocol ecosystem. They make subjective judgements about what content is relevant, interesting, or valuable to users, rather than simply indexing all content neutrally.

Feed generators consume the [[firehose]] from [[Relay|relays]] and apply their custom algorithms to select posts that match their specific curation goals. When a user requests a feed, the generator returns a "skeleton" of post preferences, which are then hydrated into full content by the user's [[Personal Data Server (PDS)]] or [[AppView]].

== User Experience ==
From a user perspective, feed generators appear as selectable feed options within client applications. Users can discover feeds through directories, recommendations, or direct links, and can subscribe to feeds they find valuable. This approach is aimed at giving users agency in selecting algorithmic experiences that best serve their interests, rather than being subject to a platform-defined algorithm. If users are dissatisfied with a particular feed's curation, they can simply unsubscribe and choose alternatives. 

== Architecture ==
The feed generator architecture follows a simple design pattern, aiming 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 <code>app.bsky.feed.generator</code> [[collection]]. This declaration includes metadata about the feed (name, description, avatar) and points to the service that hosts. the algorithm. The feed generator service itself is identified by a [[Decentralized Identifier (DID)|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 <code>getFeedSkeleton</code> request to this endpoint.

Requests to feed generators are authenticated with a [[wikipedia:JSON_Web_Token|JWT]] signed by the user's repository signing key, allowing the generator to verify the user's identity. 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 ekeleton with full post content, user information, and engagement metrics before returning it to the client application.

[[Category:Network architecture]]
[[Category:Content curation]]
[[Category:Opinionated services]]