WARNING: Extremely long and information-rich blog post incoming! I started putting this together in my head on the last day of the conference as a way to gather and report out on some discussions. Before long it turned into an entire over-3000-word roadmap.
I've been at Bluesky a little over five months, and the topics in here could potentially represent another five months of work on their own. Some of these are half-formed projects I haven't talked publicly about yet, but I really value the opportunities I get to share a bird's eye view of everything that's currently on my radar. It's good Devrel practice, and it's a privilege that I can be as transparent about it here as I can.
What I'll also say is that this writeup is very representative of my philosophy of parallel progress. While it's important for us to be present and to provide support for big product launches or org-wide pushes at times, my philosophy of Devrel is definitely a directionally-correct, many sticks in the fire philsophy. Everything is outreach, everything moves the needle. Here we go!
- 1.
Let's start with an obvious one — the Atmosphere Conference workshops, "Consuming the Atmosphere" and "Creating the Atmosphere"! Both of these were developed brand-new for the conference, with the goal of being able to repurpose them throughout the year and into the future for anyone who wants to host their own atproto onboarding. I really like maintaining these kinds of materials; if we ever get asked to do any future trainings tailored to a particular product category (and I know we will) it's usually a much lower lift to work from an existing curriculum with some specific customizations. Lots of thoughtful reuse and saved effort for Devrel, essentially.
Well, I was really happy with the way these workshops went — thank you to all of my participants for the engagement and feedback — and I can't wait to deliver them again. In the meantime, a few quick followups:
I'm going to do a pass of revisions based on feedback I got during the Workshop, like incorporating prototypey.org:
a few people found this tool I made a while ago useful in @alex.bsky.team's lexicon workshop yesterday at #atmosphereconf, so resharing here for anyone else who wants to write their lexicons in typescript prototypey.org
I'm going to make the slides available publicly alongside the exercises that are already public!
And, when those two things are done and stable, it sounds like there might be community interest in translating the workshops so they can be offered internationally:
This will be a relatively quick polish (hopefully turned around in mid-April), and the Workshops will be available as a resource to everyone from here. If you want me to run either of both of them (as 3-hour or a combined 6-hour session) anytime soon for your own org/community/other, just ask!
- 2.
Next, I need to prep for some upcoming travel before I run out of time! Specifically, I'm speaking at Write the Docs in Portland about a month from now, and after that, headed up to Toronto at the end of May for a couple events that we're developing with Gander. I'm really excited about both of these.
I also haven't had the chance to blog yet about the great inaugural atproto LA event we ran last Monday night. Turnout was even higher than I hoped, we saw some great conference talk previews from and , and our fearless leader and organizer did an incredible job with their Atlassian integration demo(!) to welcome a few different communities together. Our local group here has already committed to doing at least one larger event later this year:
Since @atmosphereconf.org 2027 is as far away as it’s gonna get from today, we’re excited to announce our commitment to host a mini-conference in LA sometime in Fall 2026! More information to come!
...and it looks like we're inspiring some other local groups to organize themselves as well! Definitely let us know if you're thinking about an event along these lines; we want to make sure you have the resources you need, and I'm really glad that atproto LA could blaze the trail here.
- 3.
Another little thing I've been cooking on lately is a blog series featuring some of the custom feed maintainers in our community, namely and (of Skyfeed).
Feeds are an interesting part of atproto because they're conceptually appealing to both a developer and a non-developer audience. The freedom to choose your own algorithm and embed within existing comms channels obviously rings true for lots of people — which is why got such a big win from being able to pair with WNYC for election coverage — and so a lot of maintainers have gotten involved in this space. Unfortunately, something I hear fairly often is that custom feeds are computationally (and, thus, financially) expensive to run compared with a lot of other atproto implementations, and that creates a tension where you have this immediately-popular product category that's more challenging to make work from an infrastructure perspective than most other projects are.
Well, this helpful data point is why my colleague 's recent blog series on feed hosting included an extra section on deployment requirements, and I want to seed the ecosystem with as many more of these real-world examples as I can. We probably haven't done as well as we could have up to now on sharing insights from running this infrastructure efficiently at scale, and I want to help change that. I'm excited that our community maintainers have expressed an openness to writing together, and I want to extend that invitation to anyone else who has insights or data to share in this department — I'll help you get that documentation into a publishable format! Look forward to this blog series coming soon.
- 4.
Another conversation I've been having via side channels lately is around supporting OIDC. Essentially, OIDC is how most consumer internet services provide the option to log in with Google, Microsoft, or other hyperscaler provider identities. It is notably email-address-centric, and consequently domain-centric.
atproto OAuth is a bit different — it's focused on DIDs (or handles that can be resolved to DIDs) rather than emails, and it's (of course) biased toward being authority-less. It is notably not domain-resolution-centric, despite us being all in on DNS in some other key areas (like handles and Lexicon resolution). As such, it doesn't quite map onto the assumptions made by OIDC.
of Tailscale approached us recently with a demo he'd made to mediate this gap, using a prototype called atlogin.net which wants to hit a WebFinger endpoint. His goal is to enable login to Tailscale — which is all-in on OIDC — using atproto identities. This is an excellent goal, particularly because OIDC implementations tend to standardize on a few big providers and it would be great to use the Atmosphere to push back on that, but the implications of making this work in terms of domain resolution are weird in a few ways. Most of the solutions we've tried to think up either a) disadvantage users who were using custom domain names, b) expose strange pseudo-handle syntax to resemble an email address where they should have been using DIDs anyway, c) or present a significant commitment in terms of identity infrastructure that we were afraid we’d end up treating as an afterthought. We really want to solve this, but it's a tricky one! I even hacked up a WebFinger branch for the reference PDS before deciding that was probably the wrong direction to take here.
One idea we thought of could involve using 's AIP gateway as a kind of OIDC-DID mapper sidecar service on the Tailscale side rather than on the Bluesky side, but that still plays quite weirdly with email domain assumptions. Anyway, the good news is that I was trying to outline this problem space while seated across from at dinner last Wednesday and he seemed to have some strong opinions, so we're keeping at it! We at Bluesky are all heavy Tailscale users and love the idea of creating more ways to use atproto identities outside of the Atmosphere, we just need to establish a working model here. Hope to have more to share soon.
- 5.
As you probably know, most of the work I was doing from about Nov - Feb was getting our new atproto docs out the door and figuring out which "docs dependencies" also needed to be updated. Two of the messiest areas of that work were a) OAuth and b) moderation.
In the case of OAuth, the work around our permission scopes and making permission requests was coming in pretty hot, and we wanted to make sure we landed something that was complete and usable, which we did. In my opinion, though, which is anecdotally shared by some of the conference attendees we talked to, this stuff can still be pretty intimidating and unintuitive to work with, and I think we want to do one more clarity pass over this part of the docs. If you have feedback here, I'd love to hear it.
In the case of moderation — and I've said this to a lot of people by now — I had to work really hard to falling into a classic commercial open source docs trap, where you wind up saying things about your product and your product's intended "golden path" by omission. This is particularly common for open source products that are free to run but challenging to host; the deployment story that actually gets documented winds up being conspicuously incomplete in a way that you have to read between the lines to understand, because filling in those gaps is actually your revenue model.
We don't have quite the same tensions here (we're not B2B-shaped, for example), but our moderation story comes closest to having the same problems. Right now, we can recommend Ozone (which we built for our own needs and works great if you have a large team of moderators working on top of an automod baseline) and/or Osprey (which provides that automod baseline but is a heavyweight rules engine requiring a lot of local tuning), and yet we know that neither of those is a great fit for small teams who need a scalable solution.
To that end: I absolutely loved 's talk about Coop, which I'm convinced will be that one-size-fits-most solution with just a little more work to improve deployment, and I can't wait to foreground it more in our docs when I can. The "I don't get it, what is everybody actually using in production" problem is really common in open source communities like ours that can be hesitant to make concrete recommendations, and I'm pumped that there's a solution on the horizon here. Look forward to these docs revisions pretty soon.
- 6.
Speaking of up above, I have been so impressed with his governance of lexicon.garden. He technically scooped us a little bit with this one when we were rewriting our docs site and thinking of adding similar features, but I can't be mad about it, since he's done so much to scaffold Lexicon publishing workflows and even provided his own MCP endpoints.
I really want to find a way to standardize these endpoints as inputs to other parts of the ecosystem; every now and then I play with additional ways of making the docs more Lexicon native, and I know that Nick takes community governance really seriously. When I was developing the "Creating the Atmosphere" workshop I had to think really hard about how to provide the right amount of guidance for designing new data models and cross-Lexicon linking, and Nick is simply ahead of the rest of us right now in terms of giving that structured data a machine-readable and human-readable home. This is up in the air, but I'm determined to pursue some more integrations here once we get a chance to nail them down.
On that note...
- 7.
There's a general sense that we could be doing more to improve the usability of our documentation with LLMs, whether it's with MCP endpoints or other ecosystem tools. I'm on the record as being a big believer in improving the machine readability and human readability of docs simultaneously rather than at each other's expense — it turns out that if you're designing for the machines in the right way, you're also helping humans.
A few weeks ago, I added kapa.ai to the atproto.com header nav as a trial integration. I particularly like Kapa because it's very good at citing and driving traffic back to its sources, and because it combines and provides insights into how each of those different sources — including user contributions — are being used in each query:
I have my own sub-roadmap for making our documentation even more accessible, and it goes something like this:
Add the ATProto Touchers Discord to Kapa as a knowledge source (and maybe add a Kapa bot to the Discord in turn). I didn't do this during our initial trial because the Discord is not currently public unlike the other data sources. I am also quite biased against the way Discord tends to trap a lot of community knowledge, and would love to open it up this way. I need to discuss with the community whether they're OK with this.
Improve the developer ergonomics around ingesting Lexicons themselves. Taking Kapa as an example, right now one of the formats it's able to ingest is OpenAPI endpoints; we currently have not especially nice Lexicon -> OpenAPI mapping in the dedicated Bluesky docs that a) takes 15 minutes for Docusaurus to build 😱 and b) is a big part of why those docs are currently in a borderline maintenance mode while we figure out how to reimplement this.
We would love to better socialize Lexicons as structured input. This is, after all, pretty much the whole philosophy behind lex and our codegen-forward approach to SDK design. The hard work is already done: Lexicons inherently get you structured data for all your app surfaces. But we need to do some additional experiments here, e.g. by publishing agent skills to v-it.org or by pushing Kapa to adopt Lexicon as a source without an OpenAPI intermediary. More here soon.
- 8.
This is mostly 's beat, and everyone ought to watch his demo and Social Components talk:
thanks everyone for the warm welcome @atproto.london! here's my demo of Inlay from today. code not ready for release yet but i'll try to get it to a releasable stage over the next weeks
Essentially, if you're a frontend head, and you're noticing that we're suddenly all spending a lot of time reimplementing the ways Lexicons should render to components on a page... you might want to consider putting those components on protocol!
Very cool idea, though I wasn't looking at this as something I'd personally be advancing. I am just-OK at frontend.
But then: I was having pre-dinner dinner with and some others on Wednesday night (technically Day -2 of the conference (it was a really good conference)), and they mentioned that they do some work in the Shopify ecosystem, and atproto doesn't have much penetration there yet, probably because Shopify developers are still all-in on reusing existing web components. The Rails ecosystem is not (yet) just fetching Lexicons in the frontend, probably because Rails has some hard data modeling requirements of its own. In other words, this might be an area where "we can just build things" has some initial hurdles, but my hypothesis is that if we get over those, we go fast. If we want adoption in this ecosystem, we probably need to seed some drop-in components. Get in touch if you want to talk about that 😊.
And this kind of obvious-but-important ecosystem integration brings me to another, bigger point.
- 9.
Big thoughts incoming: It strikes me occasionally that I am probably in something like the 90th(+) percentile of professionally conservative Atmosphere community members. Something that was really driven home for me by the conference is that nearly everyone is here because they are a visionary founder or a dedicated hobbyist, and a lot of the way we're discussing $$$ funding reflect that.
I'm here because I really like the product and I wanted a new job.
Right now, that feels so mundane as to be unfair! In these five months, I've had lots of people ask me how I got involved with the platform, and my answer is always that I liked what Bluesky was doing and applied on the strength of my experience and ideas. Absolutely everyone has been very gracious about this explanation, but more often than not, it's a bit of a surprise to them.
Here's the thing: I dislike power imbalances a lot. A lot. I don't like having conversations on topics where the subtext is that I'm drawing a salary and others are not; it's not fair, and even with all the organic enthusiasm and goodwill on earth (which I'm pretty sure I witnessed last week), that takes a toll over time. I don't think we can have a sustainable ecosystem where nearly all participants are either founders or hobbyists. (This, for the record, includes PBC — I've been consistently impressed and a little scared by how often my colleagues here are willing to summon that old founder energy). I won't go so far as to say most people, knowing how weird the industry has gotten in 2026, but many people doing the work need to be drawing "regular" paychecks for it. And that means that existing orgs have to want to pay for work on the Atmosphere.
it is my #1 structural concern and motivates a lot of what I do— we *need* to get more of the atmosphere drawing regular salaries for this work, one way or another. that could happen through existing companies feeling compelled to fund integrations; the “locked open” aspect is a key hedge here.
The good news is that I think we're in a much better position for this than we often talk about. In particular, the "locked open" hedge that got us this far makes it virtually impossible for any large-scale Lexicon-forward, AT Protocol-native work to not benefit everyone working in the ecosystem. Ironically, this is something we often say in defense of Bluesky PBC [constructively] throwing its weight around, but I think it becomes much more evidently true as soon as other BIG players get involved. And we should want them to, and to staff up, before many of us burn out.
Two talks I saw this week were really helpful on this point: 's Framework for Sustainable Projects and 's Lexicons for Enterprise Data. I highly encourage everyone reading this section and nodding along with me to check both of those out when recordings are posted, and I'm going to make sure that this is an area that Bluesky Devrel is ready to resource as opportunities come up. If you're in a position to move opportunities along, I feel extra strongly about this and would love to talk.
- 10.
I saved this one for last, because when it comes to Bluesky the app, I'm like the Baltimore Oriole: I'm not supposed to talk about it. This is because most of what I can say publicly about the app honestly just gets everyone in trouble; I'm very rarely the one doing that work, people have very different ideas about our unstated priorities, and so on. Over the weekend I trickled out some information about Bluesky shipping group DMs relatively soon after confirming it with the product team because I know a lot of journalists and others who primarily care about the app experience saw this feature as overdue:
... but I'll be honest, I was nervous about doing even that, and only did because I got to clarify something about the protocol 🤓. With that said — returning to my original thesis of making parallel progress — there is a lot of protocol-forward work in 2026 that will really, really benefit from app integrations.
Pretty much everyone was excited about our work to integrate Germ and to extend our Live Now badge to Atmospheric apps like Streamplace, and I think there will be much more to come in this department this year. I absolutely love the way that many apps (including this blogging platform) are integrating Bluesky posts as a way to thread their comments, and without giving too much away, I think that works equally well in the reverse direction. Perhaps you'd like to turn a long post thread automagically into an on-protocol long-form blog post, or paste a code sample and have it embed into a platform with proper syntax highlighting? Gosh, I would too. And that's officially getting into the realm of UX that no other microblogging platform has had yet, because they didn't have the Atmosphere 😉.
Thank you for reading this inadvertently manifesto-length post!! I really like conference "trip reports" as a way to capture in-process thoughts, and AtmosphereConf turned into an entire roadmap on its own. All of these are great Devrel surfaces to discuss further if you want to get involved! Feel free to book a meeting or just @ me.
And now: to go on vacation for a week and a half. See you on April 13!