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
prompt=create isn't universally supported across PDSs, and the OAuth flow needs updates to make account creation smoother for non-technical users.executive summary
02/22/2026
This week's call opened with a moderation stack walkthrough — Skyware for minimal labeling, Ozone for multi-user human review, and Osprey for rules-based pattern detection at scale. Signup UX got airtime too: prompt=create isn't universally supported across PDSs, and the OAuth flow needs updates to make account creation smoother for non-technical users.
The longest thread was about explaining credible exit to less technical people. offered an accessible framing for explaining the human consequences of PLC/hosts in general, but the group acknowledged the general difficulty of eyes glazing over fast when technical details are invoked. The consensus: focus on human outcomes/requirements!
On infrastructure, the following feed emerged as "a stupidly complex data problem at scale" — roughly half of Bluesky's production workload. The Postgres-to-Scylla migration went poorly and large accounts may be lossy. For app developers, there's a cheat: filter bsky follows to only those with your app's records. A related gotcha: blocks don't remove follow records, raising the question of why writing to one repo should force a write in another.
Discussion of new community projects included arabica.social (coffee journaling) and drydown.social (fragrance reviews). The call closed on legal obligations for PDS operators — the goal being to make compliance simple enough that a student hosting a project isn't scared off by regulations.
Quick links: Osprey ∙ Adversarial PLC migration ∙ Jaz on imperfection ∙ arabica ∙ drydown ∙ ATmosphereConf 2026 ∙ Lexicon Garden
table of contents
labelers
signup ux and
prompt=createdev tokens and Device Code Grant Flow
Everything Account
relays &
collectiondircontributing 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.
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.
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."
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:
Signup UX & prompt=create
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.
shared her OAuth working group proposal, which addresses some of these authorization management concerns.
Key resources:
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.
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:
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?
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, suggested "it's like lock-and-key matching but more like fingerprints that are actually unique," and offered the image of BFF heart necklaces — one half yours, one half somewhere else.
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 put it: "getting people to tune in long enough to even understand what the PLC is — is very hard ... people's eyes glazing over." noted simply: "asymmetric crypto is hard." 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. argued for it ("otherwise I feel they'll always be reserved for nerds like me"), while felt they should live on your PDS host's website, not in any particular app. 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.
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:
permissioned data and the "Everything Account"
Brief but fun thread: floated the idea of putting dotfiles on your PDS — "ultimate nerd snipe." named the vision: "everything account." pointed out the real draw would be if the data could be encrypted/private, and noted that .dotfiles are usually already public on git anyway.
Relays & collectiondir
Quick pointers to relay infrastructure resources. shared the AT Stack guide. linked 's image for collectiondir built from the Indigo repo. 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:
Lexicons
A pragmatic conversation about when you need a lexicon and when you don't. acknowledged that Blento "still doesn't have a lexicon" and formalized the vibe: "Not Everything Needs A Lexicon." 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. called the deprecated field support "vital." pointed to Lexicon Garden as the best current resource for browsing existing schemas.
Key resources:
Documentation & Contributions
The "circle of life" problem: "tried to write documentation and then it got outdated like 3 commits later." This resonated broadly.
The aspirational model: 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." added godoc to the list.
and shared interest in "for babies" / ELI5 docs and volunteered to collaborate. framed the need as three tiers: "examples/concepts/api-ref, I think we need all 3, some will be app level." pattern from JS libraries: "Getting Started/Quick Start + Important Concepts + API Type specification." pointed to Go's docs as a model: "examples/docs/howtos plus reference in a single page."
On the contribution side, pointed to the atproto-website GitHub issues and noted the team "were pretty responsive on GH, got a little typo thing merged in a couple hours." '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:
Following Feeds
The following feed is "a stupidly complex data problem at scale" — and according to a post from , 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.
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. 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:
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. noted that "the good old 'block, unblock to force unfollow' trick doesn't work around here."
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.
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 — explained their coffee journaling alpha built on ATProto.
drydown — shared their fragrance review app built on ATProto. expressed interest in discussing creator use cases together.
ATmosphereConf — 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 — 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. pointed to the cardyb endpoint that Bluesky uses for link extraction. another shared gizo, their link card generator service.
concord — shared that built an IRC client that uses ATProto auth.
Key resources:
Legal Obligations for PDS Operators
In the last stretch of the call, brought up legal compliance for PDS operators — content licensing, record versioning, and the obligations that come with hosting user-generated content. asked if this would be the impetus for record versioning and content licensing support.
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 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