This starter kit provides a foundational framework for building custom AT Protocol Feed Generators. It's designed for developers and researchers looking to implement unique content aggregation and delivery algorithms within the AT Protocol ecosystem, enabling personalized user experiences.

How It Works

The feed generator acts as a service that receives getFeedSkeleton requests from a user's Personal Data Server (PDS). It responds with a list of post URIs, optionally including metadata like repost reasons. The PDS then hydrates these URIs into full post views for the client. The core logic involves subscribing to the AT Protocol firehose (com.atproto.sync.subscribeRepos), parsing and indexing events, and implementing feed generation algorithms in src/algos.

Quick Start & Requirements

• Install dependencies with yarn and run the server with yarn start.
• Requires Node.js and yarn.
• The server listens on port 3000 by default.
• Example feed available at http://localhost:3000/xrpc/app.bsky.feed.getFeedSkeleton?feed=at://did:example:alice/app.bsky.feed.generator/whats-alf.
• Official documentation and examples are available within the repository.

Highlighted Details

• Implements AT Protocol's getFeedSkeleton method for custom feed delivery.
• Supports JWT-based authentication for user-specific feeds.
• Utilizes an opaque cursor for pagination, allowing flexible implementation.
• Provides a basic SQLite setup, swappable for other databases.
• Includes a publishFeedGen script for deploying and updating feed metadata.

Maintenance & Community

• Developed by bluesky-social.
• Community templates available in Python (@MarshalX) and Ruby (@mackuba).
• Links to community channels or roadmaps are not explicitly provided in the README.

Licensing & Compatibility

• The README does not specify a license.
• Compatibility for commercial use or closed-source linking is not detailed.

Limitations & Caveats

The project is described as a "starter kit" and "not feature complete." The provided PDS hydration logic is for development purposes, with future PDS hydration relying on an App View. The did:web setup is suitable for initial deployment, but did:plc is recommended for long-term stability.