atproto dev chat IV recap

part IV (02-22-2026)

i am human and i err! this was rendered from memory and discord chat, pls comment/DM me if you see mistakes or misrepresentations

table of contents

labelers

signup ux and prompt=create

dev tokens and Device Code Grant Flow

Everything Account

relays & collectiondir

contributing to documentation

following feeds

"blocks don't remove follow records"

community showcase

legal resources for PDS operators

Labelers: Skyware, Ozone & Osprey

Discussion started broadly with prior art and discovery of labelers.

@byarielm.fyi asked "what's the difference between Skyware and Ozone?"

The general answer: Skyware ( archived repo! ) is a minimal labeler implementation — it issues labels and sends them all to the client (no incremental backfill). Ozone is a full multi-user moderation interface for human review. And Osprey is the newest piece: an automation and data analysis engine for pattern detection at scale.

@thisismissem.social explained that Osprey "receives the events from a source, e.g., the firehose, and then based on the rules you've stored (a DSL) it can then apply those to data as it comes in. Osprey also stores all the events in a big database, which then allows you to write new rules and investigate patterns."

@byarielm.fyi summarized: "Skyware is kinda the base code you need for a labeler, Ozone provides UI and some extra db/moderation stuff, and Osprey is more pattern/rule formatting for labellers?"

Key resources:

Osprey for ATProto

Signup UX & prompt=create

@flo-bit.dev raised the signup UX question: should apps let users enter email and password on the app's own page (easier to understand, but worse for password managers — this is what Bluesky does), or redirect them to a PDS with prompt=create?

The problem that was raised is that prompt=create isn't standard and not all PDSs support it — single-user PDSs and those with registration disabled can't handle it. Updates to both the PDS and the OAuth flow itself are needed. There is reportedly energy on the Bluesky team around this.

@thisismissem.social shared her OAuth working group proposal, which addresses some of these authorization management concerns.

Key resources:

OAuth Authorization Management URI (draft)

Bluesky Cookbook

Device Code Grant Flow

Brief discussion of the device code grant flow pattern (as it relates to dev tokens for atproto apps): start the flow on one device, poll for completion, and get the token back. The open question is how DPoP works with device code grant flow (still in draft), and what happens for devices without a display.

@same.supply shared an example implementation from the atcute project.

But it was noted that ultimately most people use app passwords for programmatic access to atproto apps because they're easiest (even if they're a blunt instrument we should grow beyond).

Key resources:

atcute node-client-public-example

Explaining Credible Exit to Non-Technical Users

Yeah, totally fair, that framing was weird. Here's the fixed version:

Explaining Credible Exit to Non-Technical Users

This thread explored the perennial challenge: how do you explain PLC, rotation keys, and credible exit to people who aren't developers?

@sharpiepls.com offered an accessible analogy for explaining the relevance of PLC to new users: PDSes are houses and the PLC is like a post office. Migrating packs up your old house and builds a new one somewhere else — then you tell the post office your new address, and all your mail gets routed there instead. The group riffed on analogies further — one compared rotation keys to 2FA backup keys, @byarielm.fyi suggested "it's like lock-and-key matching but more like fingerprints that are actually unique," and @psingletary.com offered the image of BFF heart necklaces — one half yours, one half somewhere else.

@thisismissem.social offered some technical detail for the framing: "I'd just say you have a credential that you can use to manage your identity in the cloud, and when you create that credential, you register it with your identity in the cloud."

The challenge, as @sharpiepls.com put it: "getting people to tune in long enough to even understand what the PLC is — is very hard ... people's eyes glazing over." @geesawra.industries noted simply: "asymmetric crypto is hard." @zzstoatzz.io suggested that there's a "depth of the iceberg" that you don't need to invoke when getting relative normies ramped up and that the ultimate focus should be clearly explaining human outcomes.

Discussion also touched on whether rotation keys should be surfaced in Bluesky's settings under an "Advanced" menu. @geesawra.industries argued for it ("otherwise I feel they'll always be reserved for nerds like me"), while @same.supply felt they should live on your PDS host's website, not in any particular app. @besaid.zone agreed it shouldn't be a separate thing from the PDS. The secure enclave approach — storing keys in device hardware — was mentioned as a possible ideal end state.

@bad-example.com shared a post on adversarial PLC directory migration, rounding out the conversation with the question of what happens if the centralized PLC directory itself becomes hostile.

Key resources:

Adversarial PLC directory migration

Sharpie's PDS migration vlog

permissioned data and the "Everything Account"

Brief but fun thread: @geesawra.industries floated the idea of putting dotfiles on your PDS — "ultimate nerd snipe." @quillmatiq.com named the vision: "everything account." @evan.jarrett.net pointed out the real draw would be if the data could be encrypted/private, and @same.supply noted that .dotfiles are usually already public on git anyway.

Relays & collectiondir

Quick pointers to relay infrastructure resources. @thisismissem.social shared the AT Stack guide. @besaid.zone linked @zzstoatzz.io 's image for collectiondir built from the Indigo repo . @verdverm.com mentioned their atmunge project , which "produces a table with every account and collections — it's very easy to build that index, one request per account."

Key resources:

The AT Stack (guide)

collectiondir (Indigo)

https://github.com/verdverm/atmunge

Lexicons

A pragmatic conversation about when you need a lexicon and when you don't. @flo-bit.dev acknowledged that Blento "still doesn't have a lexicon" and @psingletary.com formalized the vibe: "Not Everything Needs A Lexicon." @quillmatiq.com agreed — "we can also start sans lexicon and move when we're ready, doesn't need to be a blocker."

That said, when you do use lexicons, the tooling needs work. @geesawra.industries called the deprecated field support "vital." @taurean.bryant.land pointed to Lexicon Garden as the best current resource for browsing existing schemas.

Key resources:

Lexicon Garden

Documentation & Contributions

The "circle of life" problem: @evan.jarrett.net "tried to write documentation and then it got outdated like 3 commits later." This resonated broadly.

The aspirational model: @thoth.ptnote.dev pushed for rustdoc-style generation from source annotations — "I didn't think it was possible for docs generated from source annotations to be good (I mean, have you seen doxygen?) until I saw rustdoc." @geesawra.industries added godoc to the list.

@byarielm.fyi and @chaosgreml.in shared interest in "for babies" / ELI5 docs and volunteered to collaborate. @zzstoatzz.io framed the need as three tiers: "examples/concepts/api-ref, I think we need all 3, some will be app level." @same.supply pattern from JS libraries: "Getting Started/Quick Start + Important Concepts + API Type specification." @geesawra.industries pointed to Go's docs as a model: "examples/docs/howtos plus reference in a single page."

On the contribution side, @thisismissem.social pointed to the atproto-website GitHub issues and @zzstoatzz.io noted the team "were pretty responsive on GH, got a little typo thing merged in a couple hours." @byarielm.fyi 's workflow challenge: "it's hard to read and then pause to write an issue." and suggested annotating docs with margin.at as a lower-friction way to leave notes while reading.

Worth noting was the reminder that well-articulated opinions and confusions from newcomers are super valuable signal to maintainers, and that tools like Claude can help you articulate yourself and open a github issue/discussion in a way that matches project norms.

Key resources:

atproto-website issues

Following Feeds

The following feed is "a stupidly complex data problem at scale" — and according to a post from @why.bsky.team , it represents roughly half of Bluesky's production workload. The basic flow: a post lands, a background task injects it into every follower's feed (a sorted set). Straightforward in concept, crushing at scale.

@evan.jarrett.net clarified this is specifically about "the non-algorithmic one, because you have to show every post for every follower that everyone has." Mastodon's approach: generate the following feed on demand and suspend it after inactivity. Bluesky uses ScyllaDB and does not suspend feed generation for inactive users — which contributes to the workload.

Large accounts may be lossy — if you follow enough people, you might not see everything. @byarielm.fyi linked Jaz's post on "imperfection" as relevant background.

For app developers wanting to build their own following feed without all this infrastructure, there's a cheat: take {bsky follows} minus {those without your app's *.xyz records} — essentially filtering your following list to only people who use your app.

Key resources:

Why on following feed workload

Jaz — Imperfection

Blocks Don't Remove Follow Records

An important gotcha surfaced in the following feed discussion: blocking someone on Bluesky does not delete the follow record from your repo. @geesawra.industries noted that "the good old 'block, unblock to force unfollow' trick doesn't work around here."

@verdverm.com posed the deeper question: "why should block activity force some unfollow? Or generalized, why does writing a record in one repo force a write in another repo?" — highlighting a fundamental design tension in how repos interact.

@taurean.bryant.land offered a practical angle: using the follow graph as a follow recommendation system to build a new social graph, rather than trying to force cross-repo writes.

Community Showcase

arabica — @pdewey.com explained their coffee journaling alpha built on ATProto.

drydown — @taurean.bryant.land shared their fragrance review app built on ATProto. @sharpiepls.com expressed interest in discussing creator use cases together.

ATmosphereConf — @psingletary.com ran a poll: 42% virtual, 33% IRL, 17% "what's that?", 8% nah. The conference is in Vancouver, March 26-29, 2026. Several attendees expressed they'd attend virtually due to not feeling comfortable leaving the US right now.

atproto table at local events — @sharpiepls.com mentioned hosting an ATProto table at their local event the following week.

OG/link preview issues — one call member raised issues with Bluesky's handling of Open Graph previews for dynamically generated images. @sri.xyz pointed to the cardyb endpoint that Bluesky uses for link extraction. another shared gizo, their link card generator service.

concord — @distributed.camp shared that @dollspace.gay built an IRC client that uses ATProto auth.

Key resources:

arabica (alpha)

arabica on Tangled

drydown

ATmosphereConf 2026

cardyb

gizo

concord

Legal Obligations for PDS Operators

In the last stretch of the call, @chaosgreml.in brought up legal compliance for PDS operators — content licensing, record versioning, and the obligations that come with hosting user-generated content. @tynanpurdy.com asked if this would be the impetus for record versioning and content licensing support.

@jackvalinsky.com raised the question of how compliance records should be structured — whether to use site.standard or a dedicated lexicon, given the need for versioning and tombstoning. One approach discussed: using the CID of a record as the rkey when creating it, then linking back on updates, giving you a content-addressed history with a mutable pointer to the current version.

The motivating concern, as @jackvalinsky.com put it: "we need to make it simple and straightforward to be informed because we want some random student to host a project and not be scared because of regulations that they are doing it wrong."

All links

Osprey for ATProto ∙ OAuth Authorization Management URI (draft) ∙ Bluesky Cookbook ∙ atcute node-client-public-example ∙ Adversarial PLC directory migration ∙ Sharpie's PDS migration vlog ∙ The AT Stack (guide) ∙ collectiondir (Indigo) ∙ Lexicon Garden ∙ atproto-website issues ∙ Why on following feed workload ∙ Jaz — Imperfection ∙ arabica (alpha) ∙ arabica on Tangled ∙ drydown ∙ ATmosphereConf 2026 ∙ cardyb ∙ gizo ∙ concord ∙ thisismissem on infra/apps/moderation