Call for Developer Projects

[bnewbold]

The last few weeks have seen a swell of developer interest in atproto. Welcome! The protocol is maturing, and now is a great time for early adopters to jump in and start building. This post lists some projects which we think would be good fits for the protocol, and could be built by independent teams today. They span the range from helper tools to full applications.

As a general disclaimer and reminder, public data in atproto is globally broadcast. The protocol does not yet have support for restricting visibility of content. This means that care needs to be taken both when designing projects and communicating them to end users.

Entire Social App Categories

It is possible to build entire new social apps on atproto, making use of existing infrastructure, tooling, and user communities. Some apps are a better fit right now than others. Here are a few patterns we think could be successful today. See the Statusphere Tutorial, and "What does an AppView Implementation Entail" for an overview of what goes into building a full application.

Reviews and Recommendations: a broad category of social apps which would fit quite well with the atproto model are social reviews and recommendation services, for almost any type of venue, content, or artifact: restaurants and venues, companies and services, film and other media, durable goods and tech products, etc. Moderation primitives (like labeling and Ozone) can be used to mitigate fake accounts and rating manipulation. Existing databases and identifiers (eg, IMDB, MusicBrainz, Wikidata, ISBNs, SKUs) can be used to disambiguate subjects. Existing social graphs (like the Bluesky follower graph) could be used to bootstrap social recommendations.

Comments Sections: not all content on the web needs to live in the protocol itself. Hybrid systems are possible, leveraging the bsky post schemas and APIs to provide comment sections for existing blog posts and other web pages. A Tech Talk session from October got together several existing projects in this category.

Media Feeds: another hybrid approach is to create atproto records which link or represent off-network content, and copy the bsky "custom feed generator" pattern to build content feeds for various media types. For example, building feeds for blog posts, video channels, podcasts, news articles, books, and more. These could potentially build on top of the bsky post schemas, though the volume of automated and duplicate posts could be unwanted. Custom schemas and records might make more sense.

Question and Answer: collaborative knowledge bases, or more casual/local advice.

Long Form Content: there are already some great projects implementing blogging on atproto, including https://whtwnd.com/. More specific article and essay formats might benefit from custom interfaces and schemas: scholarly articles, interactive explorations, travelogs and city guides, route descriptions, technical documentation, photo-intensive magazine articles, etc.

Creative Coding: small snippets of code can fit directly in records, or larger code can be stored as text "blobs". Demo scene, shadertoy, live coding, WASM toys, Processing/Arduino, code golf, regex sharing, and more. Be sensitive to security concerns whenever untrusted code is being distributed and executed!

Media Scrobbling: "what am I listening to" style social sharing. Can also extend to reading, watching, radio, and more. As with the "Reviews" category above, can build off existing databases and identifiers. teal.fm is a new project in this space.

Guides and Recipes: food recipes are the classic example, but there are a wealth of "how to do it" apps and communities, ranging from cocktails, to craft projects (Instructables), to repair guides (iFixit), gardening projects, etc.

Tagging and Curation: collecting, organizing, and annotating virtually any type of content. URLs on the web, media by identifier, locations on Earth, and more. This can span bookmarking sites like del.icio.us, media gallery sites like flickr.com, mood boards, bibliographies (and aggregations like OpenSyllabus), starter packs, and more.

Gaming Society: modern gaming involves huge communities and social structure: guilds, achievements, and more. Social features and identities built on atproto would work across ecosystems, platforms, and vendors. Sharing Factorio blueprints? In-character D&D personas and profiles? High-score leaderboards?

Governance and Civics: the strong identity and auth system (DIDs and OAuth) could be used as part of organizing and governance systems like Loomio, or the patterns described in CommunityRule. These could apply to other social web systems (eg, social structures for operating an Ozone instance), or for projects, clubs, and other self-organized groups.

Classifieds: for sale or free offers, housing rentals, and more. Would likely be a hybrid with systems that can enable private communication, but there are common needs to blast out public notices and make then aggregatable and discoverable. Smoke Signals is an existing project to do event listings.

Portfolios and Job Boards: both the employer side (position listings), and employee side (looking for work, skills). Field-specific portfolios for artists, academics (publications, writers and actors, software developers, etc. Would require careful thought about which aspects are truly public or require more privacy.

Protocol Infrastructure

Network Observatory: there are several projects which aggregate basic metrics about the network. Researchers have started measuring and documenting aspects of the protocol. "Observatory" projects could provide generic analysis tools that would allow users and communities to introspect and understand their own dynamics. Leaderboards can have perverse incentives, but carefully designed ones could provide insight into new apps and usage patterns in the network, and help prioritize moderation issues and resource allocation.

Language SDKs: there are official and community SDKs in a couple popular programming languages, but there could always be more. Check out the SDK List and Community Showcase for existing SDKs, which might welcome contributions. There is an overview of What Goes Into an SDK, and Interop Test Files, which could be helpful for new projects. There is no SDK for the Java/JVM ecosystem yet.

Generic Datastores and "Views": today, most AppVIews are implemented from scratch. Some app features may always need custom infrastructure, but there are several common patterns and use-cases that could probably be met with generic indexing using common code (frameworks) and infrastructure. For example, blobs can be extracted in a generic way, so a generic image CDN is possible. Label subscription and "hydration" is fairly generic. Entire records could be added to generic "document" datastores and queried using systems like OpenSearch/ElasticSearch. DIDs and AT URIs can be parsed from records, and "backlink" databases indexed, perhaps in a graph database.

PLC Replicas and Auditing: the PLC directory has an export/audit API endpoint, which facilitates mirroring, archiving, and auditing the full PLC operation history. One next step in this area for the directory itself will be to implement Transparency Logs (tlog) on all operations. In the meanwhile, tooling and projects to monitor and replicate the directory help improve trust in the overall system.

PDS Implementations: the protocol is stabilizing and we encourage folks to both implement and operate independent PDS instances in the live network. This includes "open registration" services at scale. See "What does a PDS implementation entail" for some scope details.

Relay Implementations: relays are fun to implement! They have a clearly delineated job, and a bunch of network and data structure performance considerations to toy with. It would be great to have a performance leaderboard comparing relay implementations in Rust, Seastar, Scala, Go (like our existing bigsky implementation), and more. Could you have a relay backed with S3-compatible object storage? Or build on Kafka? There are also several tweaks and extensions to the relay role that are possible, like filtering by NSID, or using alternative transports.

Datastore Adapters: generic tooling which consumes from the firehose (and backfills from the network), and pushes data into generic datastores like Clickhouse, Elasticsearch, PostgreSQL, parquet, and others. Also connectors to event processing systems like Kafka, Redis Streams, or nsq.

Account and Identity

Account Backups: services and tools to help backup account data and identity control. This could be things like cronjobs which do daily repo CAR file and "blob" backups to an S3-compatible bucket, or Shamir secret sharing between friends to recover PLC rotation keys. Monitoring and alerting for unexpected account changes.

PLC Rotation Key Management: most users in the network today do not have complete control over their network identity, because they have not registered a locally-controlled rotation key. Getting everyday users in control of their identities will take work, but the first steps are to increase accessibility of this to developers, technical users, and high-profile / high-value accounts. This could include command line tools, integrations in password managers and "wallets", support or plugins for hardware enclaves, as well as tutorials and guides to security best practices.

Account Data Exports: the current repo export format is CAR files. These are complete, app-neutral, can be used for account migration, and have a well documented format. They can be processed with tools like 'goat', but are not particularly accessible for many users. More accessible tools to convert and explore CAR exports would be helpful: indexing into sqlite, converting to spreadsheets (CSV) or JSON, displaying and browsing bsky posts, etc.

Bluesky Microblogging

Feeds: control your scroll! Everybody has different ideas about how content feeds should work. Check out our TypeScript tutorial and template project (https://docs.bsky.app/docs/starter-templates/custom-feeds), or similar frameworks in other languages.

Labelers: labeling services are the main component of the composable moderation system in atproto. Moderation is hard work, and we think some types of labeling projects are more likely to succeed than others. Some types we think would be appropriate as smaller projects:

• assessing field-specific misinformation, such as debunked articles or urban legends
• profession-specific or community-specific misbehavior, such as artistic misattribution, scientific misconduct, or cheating at games
• flagging popular engagement farming accounts which re-post scraped images without attribution
• detecting and hiding "old memes" and stale discourse
• hiding annoying or unwanted content (which does not otherwise violate community guidelines)

Bots: simple interactive bots also make a good starter project. Be sure to clearly describe the nature of automated accounts, stay within rate-limits, and don't initiate interactions with human users (they need to take the first step, otherwise it is spammy).

Client Apps: web, mobile, desktop, receipt printers, and more.

What Not to Build?

There are a couple project ideas that get proposed frequently, which we think might not be good starting places.

Private Data in Public Repos: a lot of folks want support for private/shared content in atproto. We hear you! And are designing support for this into the protocol itself, though it will take some time. In the meanwhile, we think that encrypting private data and putting it in records in public repos is not a good idea. For example, using PGP, age, NaCL, atproto signing keys, or other secure cryptographic systems. Repo data is publicly broadcast, and ciphertext should not be.

If folks want to implement less-visible content in atproto projects today, we recommend doing what we did for the temporary Bluesky Chat DMs system: implement a centralized server and talk to it over Lexicon APIs using service proxying (aka, service authentication). In the future, when private data is ready to use, it should be possible to have users migrate their content over.

Community Notes: we are pretty enthusiastic about collaborative annotation systems like Community Notes! This is a great type of project to work on, but duplicating community efforts would be bad, so we encourage folks to contact and partner with us before jumping in directly.

Engagement Farming, Scraping, and other Spammy Behavior scraping and reposting content from the internet can result in easy engagement, but degrades the network in the long run. This is especially true when attribution is missing!

Misleading Accounts: there are plenty of fake and inauthentic accounts on the internet already. Wiring up LLMs as chat bots is not welcome unless they are clearly labeled as such.

[str4d]

PLC Rotation Key Management

I'm building the plc Rust CLI tool with the current goal of enabling users to use YubiKeys for managing their own rotation keys.

PLC Replicas and Auditing

I accidentally implemented a PLC mirror in the above plc binary for testing purposes, but plan to make it a fully-compatible mirror endpoint and am interested in collaborating to add tlog support.

[imax9000]

I already made a ready to deploy plc mirror: https://github.com/bsky-watch/plc-mirror

[nperez0111]

I'm building a better Goodreads called Book Hive, I'll be posting my progress on this Bluesky thread: https://bsky.app/profile/nickthesick.com/post/3lb7ilmgrxk2u

The hope is to:

• Manage your read & want to read books
• "Buzz" about the books with friends with Bluesky comments
• Have a much nicer UI/UX
• Be decentralized, take your books to other apps if you want to!

[Shelob9]

I am working on Skygram.app right now it's an Instagram-looking feed viewer for Bluesky.

I am planning on short term to add oAuth and once logged in the ability to create different views of images you've posted.

Could make it into more of a stand alone, photo sharing app with an Appview, in future, but not sure if that makes sense.

GitHub repo is linked in the header

I am @Josh412 on Bluesky,

[natepmay]

Thanks--this is exciting! I just released a database of bsky/atproto apps and tools at balloon.fyi. It's the most comprehensive one that I know of at the moment. Looking forward to seeing it grow with submissions.

[Clay-Ferguson]

My side project is a block-oriented Hierarchical CMS (like a tree-based version of Jupyter Notebooks, without the code), that I want to turn into a Social Media client for atproto. Since all conversations are actually hierarchical (i.e. replies being child nodes of a parent) my app architecture does well as a collaborative tool:

Quanta on Github

[snarfed]

Hell yes! Love it.

Network Observatory: there are several projects which aggregate basic metrics about the network. Researchers have started measuring and documenting aspects of the protocol. "Observatory" projects could provide generic analysis tools that would allow users and communities to introspect and understand their own dynamics. Leaderboards can have perverse incentives, but carefully designed ones could provide insight into new apps and usage patterns in the network, and help prioritize moderation issues and resource allocation.

We've been talking about this for a little while in https://discord.com/channels/1097580399187738645/1305571488555864136 , lots of discussion there.

Famously, all of the Bluesky network's data is public and downloadable. I'd love to see it backfilled and streamed ongoing into BigQuery or some other publicly accessible data warehouse. We regularly see questions like "how can I find all lists," "how can I find all labelers," "how many people do X," "is Y growing or shrinking," etc. This could answer those questions.

Afaik the cumulative size of all records is still well under 1TB, and I expect query volume would be low. Feels like this could happen for as little as $5-20/mo on BigQuery.