AT Protocol Developer Call Recap

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

Topics Covered

Germ integration & permissioned data

Blacksky and community-driven development

Onboarding, identity, and the PDS question

LLMs in ATProto development

Germ Integration & Permissioned Data

The call opened with the Germ DM button — the first non-Bluesky lexicon rendered natively inside bsky.app. When a Germ user connects their account, a com.germnetwork.declaration record is written to their PDS, and Bluesky's appview renders a "Germ DM" button on their profile.

@thisismissem.social worked directly with the Germ team on the OAuth aspects of the integration and walked through the technical details, like the messageMeUrl link deliberately omitting key material — which is instead discovered in the declaration record — allowing for key rotation without forcing appviews to deal with cryptographic complexity. The record includes a showButtonTo field that lets the appview decide whether to render the button based on the viewer's relationship to the profile owner (everyone, users I follow, or none).

It was mentioned that @ducky.ws discovered you can write anything into a com.germnetwork.declaration record and Bluesky will render it — the appview doesn't validate the contents beyond checking for the record's presence. Bluesky does show a "Leaving Bluesky" interstitial for unknown domains.

The Germ integration connects to the broader permissioned data conversation happening at the protocol level. @dholms.at 's recent diary post on design tradeoffs (why not E2EE for permissioned data?) was referenced in the Bluesky PBC's office hours the Friday before. the Germ record itself is public, but it coordinates controlled interactions — who can message you, under what conditions — through that public record. the Bluesky team also called out that Germ has shipped E2EE as a layer on top of AT Protocol.

Key resources:

Render a Germ DM Button in Your AppView — Mark's guide for appview developers

com.germnetwork.declaration on Lexicon Garden — Schema reference

Ducky's post about the record

Permissioned Data Diary 1 — Daniel Holmgren on E2EE tradeoffs

Blacksky & Community-Driven Development

The call expressed excitement about the Blacksky team's recent work, continuing to expand their own infrastructure: OAuth login support , and community-only posts visible from the Blacksky but scoped away from the wider network. As the Bluesky PBC team noted in their office hours the Friday before, "they're not just forked, but they're building their own infrastructure." and "can't say enough good things" about their impact on the broader ecosystem.

Today's call reflected on drama downstream of these community-only posts, as "objections" arose from a vocal minority in the ATProto dev community who (non-exhaustively) called community-scoped posts "vendor lock-in" and suggested community safety features as being somehow against the protocol's ethos. Comparisons were made to historical complaints aimed at Tangled for not using "git-in-your-PDS". Call participants generally pushed back on what could charitably be called the salient points of criticism among the vocal minority, as in: Blacksky's implementation is within the intended use of the protocol (especially while permissioned data is WIP) and that communities like Blacksky are building to serve real human needs — safety, identity, belonging — with the protocol as it exists today. Their work (along with that of other demographic-based communities like Northsky ) puts healthy design pressure on protocol developers to better support things like community-scoped content natively for all future communities leveraging the protocol.

Discussion also touched on social norms: the dynamics of quote-posting vs. screenshotting ("screenshotting removes consent and agency"), how 300 characters makes nuance hard, and the value in doing the work of talking to people you disagree with instead of about them.

The dominant sentiment expressed on the call was that most people (literally on the call, but also in the online circles of those who were on the call) who are building on ATProto are genuinely excited and inspired by Blacksky's progress, especially as of late.

One call member voiced a misconception that "Blacksky took money from Peter Thiel", which appears to have stemmed from mistaking @blackskyweb.xyz with https://blacksky.com/ , which was swiftly corrected by numerous folks including @thisismissem.social and prompted a short discussion about spreading misinformation.

Key resources:

Blacksky community-only post example on PDSls

Blacksky (the correct landing page)

Money for Mutual Resilience: Introducing Blacksky Cash

Onboarding, Identity & the PDS Question

This was the longest thread of the call and connected several (well-known) problems: How do you onboard users who've never heard of AT Protocol? How should apps handle identity? And what do you take on when you decide to host a PDS?

The Onboarding Problem

If every app says "sign in with Bluesky," you're centralizing on Bluesky. If you ask users to "choose a PDS," you've lost them. The middle ground: apps offer their own create-account experience. OpenMeet has done this by running a PDS behind the scenes and migrating existing users onto it. Tranquil PDS — a from-scratch PDS implementation with Google and GitHub login — is being adopted by projects like Witchsky.

@evan.jarrett.net : what makes sense to most people is "create an account." Having a PDS for your app is probably what most people want, but they won't understand they can use that identity everywhere.

Profile Per App

A prominent perspective was that apps should maintain their own profiles (using their own lexicons or something like site.standard.* for generics) and offer to import from Bluesky or other known apps — but not require an existing Bluesky account. A gravatar-like tool for managing profile data across apps came up as a community need; @thisismissem.social noted this would ideally live in the PDS account view itself.

@pdewey.com raised a concrete version of this: they're building an app that will have users with no Bluesky account, and they're figuring out how to handle display names and profile pictures.

Legal Obligations

Hosting a PDS to own the create-account experience means inheriting legal responsibilities. @chaosgreml.in flagged this: CSAM reporting, copyright compliance, the Stop Fakes Act, and content moderation obligations for user-generated content. Many indie developers building on the protocol may not be thinking about this enough.

@chaosgreml.in has it on their list to assemble community resources, and there's a stub in the Discourse from @bmann.ca

Branding

"Bluesky is Kleenex to the tissue that is AT Protocol" ( @pinkhatbeard.com ) . @christian.bsky.social 's Ecosystem Action working group is researching ecosystem brand and UX needs. Moving away from *sky as the default naming convention would help.

Key resources:

OpenMeet: Your Identity, Your Events

Running a PDS for Your App

Tranquil PDS source on Tangled

Christian's Ecosystem Action research

Hitchhiker's Guide to the Atmosphere

Beyond the Statusphere: Resolving the User's PDS

ATProto Code of Conduct

LLMs in ATProto Development

This came up organically toward the end of the call. A poll by @psingletary.com in the Discord chat showed 70% of attendees actively use LLMs for coding, 20% have dabbled, and 10% don't.

We covered how LLMs are useful for navigating and interpreting the growing ATProto ecosystem (i.e. "agentic discovery"). Lexicon Garden ( @ngerakines.me ) indexes 1,298+ lexicon schemas across the atmosphere. pub-search and GreenGale both offer semantic search over standard.site publications — useful for finding prior art across Leaflet, pckt, Offprint, Greengale, Whitewind, and other publishing platforms. Pairing these with LLMs helps developers compare lexicon approaches, understand how schemas relate, and scaffold implementations.

Agent skills — structured markdown files that encode domain-specific knowledge for LLMs (see agentskills.io ) — came up as a pattern worth exploring. In particular, writing skills from first principles for your own needs, then read skills from experienced engineers like danabra.mov and mitsuhiko.at to level up.

Practical recommendations from the chat:

learning-opportunities — A Claude Code skill for deliberate skill development during AI-assisted coding

get-shit-done — Meta-prompting and spec-driven development system

claude-pilot — Spec-driven workflow with enforced tests and quality automation

serena — Claude Code addon

Deep Background — A "superprompt" for making LLMs better at research

Cross-platform development also came up (porting Python to Go, building for iOS and Android), with Skip shared as a tool for building native apps on both platforms from a single codebase.

@thisismissem.social closing advice for people learning to code with LLM assistance: learn the overall syntax of the language you're working with so you can ask better questions. She broke programming languages into three families — C-like, Python-like, and Haskell/functional — and suggested understanding these paradigms at a high level makes you more effective with the tools.

All links: Germ DM button guide ∙ com.germnetwork.declaration on Lexicon Garden ∙ Ducky on the Germ record ∙ Permissioned Data Diary 1 ∙ Atmosphere Team Office Hours Feb 13 ∙ Blacksky ∙ Blacksky Cash ∙ Blacksky community-only post on PDSls ∙ OpenMeet: Your Identity, Your Events ∙ Running a PDS for Your App ∙ Tranquil PDS on Tangled ∙ aktivi (events on ATProto) ∙ Christian's Ecosystem Action ∙ Hitchhiker's Guide to the Atmosphere ∙ Beyond the Statusphere ∙ ATProto Code of Conduct ∙ PDS rate limits docs ∙ Lexicon Garden ∙ Lexicon Garden intro ∙ eu.lexicon.garden ∙ pub-search ∙ GreenGale ∙ Deep Background ∙ learning-opportunities ∙ get-shit-done ∙ claude-pilot ∙ serena ∙ Skip ∙ Why on LLM coding ∙ Smoke Signal

special thanks to @thisismissem.social and @heika.dog for reaching out and offering corrections to this post, i appreciate you :)