n8

AT Protocol Developer Call Recap

ATProtoDevChat part III (02/15/2026)

February 15, 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

Topics Covered

  • Germ integration & permissioned data

  • Blacksky and community-driven development

  • Onboarding, identity, and the PDS question

  • LLMs in ATProto development


executive summary 02/15/2026
The Germ DM button is the first non-Bluesky lexicon rendered natively inside bsky.app. @thisismissem.social, who worked with the Germ team on the OAuth implementation, walked through how the com.germnetwork.declaration record works. The broader permissioned data conversation is happening at the protocol level — @dholms.at's recent diary post on E2EE tradeoffs was referenced — and the Germ integration is a real-world example of apps coordinating controlled interactions through public records.

executive summary 02/15/2026

The Germ DM button is the first non-Bluesky lexicon rendered natively inside bsky.app. @thisismissem.social, who worked with the Germ team on the OAuth implementation, walked through how the com.germnetwork.declaration record works. The broader permissioned data conversation is happening at the protocol level — @dholms.at's recent diary post on E2EE tradeoffs was referenced — and the Germ integration is a real-world example of apps coordinating controlled interactions through public records.

We discussed Blacksky showing off community-only posts and full-OAuth support. The call mirrored the evident excitement expressed by the overall ATProto community to these updates and reflected on a vocal minority objecting to community-scoped content as "vendor lock-in." Opinions on the call broadly disagreed with such criticism, as in, Blacksky's community-only implementation is well-within the intended use of the protocol and explicitly lauded by the protocol developers at Bluesky PBC: projects like Blacksky are serving real community needs in the wild and their work puts healthy design pressure on the protocol to be better for everyone.

We spent a big chunk of the call on onboarding, identity, and what it means to run a PDS. Apps like OpenMeet and Tranquil PDS are already offering their own create-account experiences. But hosting a PDS means inheriting legal obligations (CSAM, copyright, the Stop Fakes Act) — an area that needs community resources. The branding problem persists: "Bluesky is Kleenex to the tissue that is AT Protocol."

The call wrapped with a conversation about LLMs in development — 70% of attendees use them actively (per a poll in Discord). LLMs paired with ecosystem tools like Lexicon Garden, pub-search, and GreenGale — the latter two offering semantic search over standard.site publications — help developers navigate the growing body of lexicons and prior art. Agent skills (structured markdown for LLMs, see agentskills.io) came up as a way to encode and share ATProto-specific knowledge.

Quick links: Germ DM button guide ∙ Permissioned Data Diary 1 ∙ Blacksky ∙ OpenMeet: Running a PDS for your app ∙ Lexicon Garden ∙ Christian's Ecosystem Action


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 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 with https://blacksky.com/, which was swiftly corrected by numerous folks including 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.

: 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; noted this would ideally live in the PDS account view itself.

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. 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.

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

Branding

"Bluesky is Kleenex to the tissue that is AT Protocol" () . '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 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 () 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.

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 and for reaching out and offering corrections to this post, i appreciate you :)

Subscribe to n8
to get updates in Reader, RSS, or via Bluesky Feed

atproto