atproto dev chat V recap

i am human and i err! this was rendered from memory, AI-notes, and discord chat (thanks to @thisismissem.social for edits). pls comment/DM me if you see mistakes or misrepresentations

table of contents

Infrastructure Patterns & Costs

The early part of the call was trying to figure out what useful advice actually looks like for builders at different stages. A useful framing that emerged: there are roughly three tracks, and the tradeoffs are different enough that you almost need to give different advice to each.

Track 1: client-only. If you don't need your own backend, don't build one. Tools like Microcosm's Constellation and Slingshot let you bootstrap an app that reads from the network without deploying anything. This is a real path and worth surfacing explicitly — a lot of people reach for infrastructure they don't actually need yet.

Track 2: managed services (Fly, Railway, Render, Neon, etc.). You need some backend — a database, some server-side logic — but you don't want to think about bare metal. These platforms are genuinely convenient and cheap to start, but you're paying for that convenience, and the billing model is hard to reason about in advance. Margin was referenced as a recent example, whose bill came in higher than projected; they were running multiple vendors together and had large network egress concerns, illustrating the challenge. Ted brought up The call opened with a conversation about what useful infra advice actually looks like for ATProto builders at different stages. A useful framing emerged: there are roughly three tracks — client-only (use Microcosm/Constellation, skip the backend entirely), managed services (Fly, Railway, Render — convenient but you're paying for that convenience), and bare VPS (Hetzner etc. — best economics but you own everything). The documentation that exists today doesn't make these distinctions, which means people are making avoidable early mistakes. flo.bit shared real numbers for blento (~$18/month, ~650 users) and walked through a Cloudflare Workers r/place clone that runs on the free tier. The Margin story came up as a cautionary tale for managed service egress costs.'s scaling journey as a useful external reference — not ATProto, but a clean example of how the cost curves on these platforms can surprise you at growth inflection points.

There was a lot of energy around how to share patterns. The room likes the idea of a structured interview series: document real app view architectures, costs, and tradeoffs in blog format. @chaosgreml.in, @flo-bit.dev, @byarielm.fyi, @thisismissem.social, and @zzstoatzz.io are going to develop a template together. Anything beyond "the code is on GitHub" was the bar — we need more.

@thisismissem.social shared that Blacksky released their production AppView — the first drop-in replacement for Bluesky's proprietary data plane. Emelia also shared work-in-progress Adonis.js packages for building ATProto apps with a batteries-included feel.

The call closed on a teased major announcement for Monday morning (March 9, ~10–11 AM PT) that supposedly benefits "the entire open social web." Not the ActivityPub bridge. Probably auth-related. We'll see.

Track 3: Hetzner / bare VPS. You know what you're doing, you want the best unit economics, and you're willing to own the setup. This means handling observability, log management (OTel), database backups (dbmate), and responding manually to growth events since there's no autoscaling. High ceiling, high floor.

The tension the room kept returning to: you want to give clear advice, but the right answer is genuinely different depending on where someone is. The pattern documentation that exists today doesn't make these distinctions well.

Real numbers from the call: flo.bit's blento runs ~650 users for ~$18/month — Cloudflare Workers Pro ($5), a Fly.io Caddy instance + IPv4 for a custom domain ($7), Umami for self-hosted analytics ($6). n8 linked plyr.fm/costs. For a concrete example of what's possible on the free tier: flo.bit's r/place clone on ATProto ingests ~20M Bluesky like records per day and runs entirely on a Cloudflare Worker free plan. A worker fires every minute, aggregates all likes from the last minute, and writes the result to a single KV entry (~3,600 writes/day). Clients pull from KV (up to 1 minute stale) then connect to Jetstream from that timestamp for live updates. Worth reading if you're trying to understand what Cloudflare Workers can actually do before paying for anything.

Key resources: plyr.fm/costs ∙ blento ∙ atmo.games/thousands ∙ Margin status post ∙ bluesky-social/cookbook ∙ bluesky-social/deploy-recipes ∙ roadmap.sh/full-stack ∙ rusty_statusphere_example_app

Knowledge Sharing Formats

The three-track framing above is exactly why the room felt like the real work is just talking to people — find out what they built, what track they're on, what surprised them, and write it up. That's more useful than any amount of generalized advice.

The room liked blog-style interviews over surveys — you lose too much nuance in a form. Consistent format, real numbers, and a "what surprised you" question (e.g., Bluesky reportedly spends ~50% of their infrastructure cost on following feeds) would make for genuinely useful reading. @jaredlemler.bsky.social suggested recording calls and hosting planned guests around recurring topics; the room was receptive.

The bar @zzstoatzz.io set: "anything beyond 'the code is on GitHub, go read it' is better than nothing." Bryan added that once you have enough data points, structured comparisons — rows and columns — get really powerful.

Action item: @chaosgreml.in, @flo-bit.dev, @byarielm.fyi , and @zzstoatzz.io are going to coordinate async on a basic interview template. First app view TBD.

Blacksky's Production AppView

@thisismissem.social shared that Blacksky released their production AppView: blacksky-algorithms/atproto. It's the first drop-in replacement for Bluesky's proprietary data plane, based on the reference implementation (note: the PostgreSQL-based one in the Bluesky ATProto repo is local-dev only; Bluesky's actual data plane is proprietary and closed) but production-ready — with performance optimizations, caching, and community features. Not accepting contributions or PRs at this time.

Key resources: blacksky-algorithms/atproto ∙ Blacksky community feed API

Profile & Badge Systems

@flo-bit.dev proposed ATProto-wide badges — self-labels for interests, roles, etc. — as a topic. Discussion was relatively brief but surfaced a few takes worth noting.

The floating idea was a self-modifying faceted system: users add custom facets as needed, pull relevant data rather than pre-defining everything. The room generally felt it's better to let users define within a standards framework than to standardize prematurely — the cost of missing use cases through early lock-in is high.

Relatedly, CaptainCalliope brought up RSS's history: it survived as long as it did largely because of podcasts, which makes the idea of a standard.site analogue for podcasting historically interesting. n8 and Jared had talked about this the Friday before. Consensus: a little early to standardize, but worth keeping on the radar.

Community Sustainability & atprotofans

Apps relying on Microcosm/Constellation for data retrieval should support Fig financially — GitHub Sponsors etc. Attribution requirements similar to iOS license disclosures were suggested as a model.

@zzstoatzz.io mentioned atprotofans.com: currently gated binary (paid/unpaid), with no tiered access model. More expressive subscription options are needed; bandwidth is the constraint.

@nichoth.com also flagged the data-star framework as worth looking at for backend-first development patterns.

AI & Development Tools

This came up early and recurred throughout. LLM adoption is real among builders on this call — some reporting 4+ hour workdays with AI assistance. The usual tensions surfaced: tool dependency vs. building actual understanding, anti-AI sentiment on Bluesky vs. pragmatic usage by the people actually building things.

The real infrastructure knowledge gap isn't LLMs per se — it's that LLMs help you scaffold something that works before you understand what it costs to run. Validation is hard when you don't have a mental model for what you're deploying. Better ATProto-specific educational resources would help.

Charcoal Safety Tool

Bryan is building a proactive toxicity identification system. It uses language models to classify engagement patterns — specifically targeting users with a history of toxic behavior plus topic overlap with the current user, who aren't yet followers. Proactive muting and blocking with a review queue. Built on top of Roost safety tooling from GitHub, and referencing the Uli Learning Guide.

Alpha release was expected within days of the call; broader network intelligence scaling is planned.

Key resources: Uli Learning Guide

Frameworks for Building ATProto Apps (Adonis.js)

@thisismissem.social shared that she's been building ATProto-specific packages for Adonis.js aimed at making app development feel batteries-included:

Still early — bugs happen, breaking changes are being managed. Adonis.js v7 updates to both packages are in progress.

Key resources: adonisjs-atproto-oauth ∙ adonisjs-atproto-tap ∙ Adonis.js

Teased Announcement

Someone on the call has been sitting on a major announcement for 2–3 weeks. Dropping Monday, March 9, ~10–11 AM PT. Said to benefit "the entire open social web." Not the ActivityPub bridge. Probably something auth-related, but nobody confirmed that. Watch your feeds.

all links

plyr.fm/costs ∙ blento ∙ atmo.games/thousands ∙ Margin status post ∙ Margin opencollective ∙ blacksky-algorithms/atproto ∙ Blacksky community feed API ∙ adonisjs-atproto-oauth ∙ adonisjs-atproto-tap ∙ Adonis.js ∙ bluesky-social/cookbook ∙ bluesky-social/deploy-recipes ∙ roadmap.sh/full-stack ∙ rusty_statusphere_example_app ∙ Uli Learning Guide