Last week, I took the first steps toward expanding the types of content supported on AT Explore. I started working on Leaflet documents and began laying the foundation for ActivityPub integration.
I’ve wanted to support custom lexicons for a while. Right now, all protocol content shows up on AT Explore, but most record types outside the official Bluesky schemas just fall back to a generic UX. It works, but it’s not really user-friendly. I want AT Explore to eventually handle as many record types as possible.
Why Leaflet?
Leaflet felt like an interesting place to start. It’s been popping up all over Bluesky lately, and once I realized it stores records directly in a PDS, I figured it was worth adding. Long-form content is a bit different than what you normally see on the AT Protocol, which is mostly short-form. That brought along some new considerations for me, since so far I’ve really only supported short-form content. It also introduces new UX challenges. I’ve actually been kicking around the idea of showing feeds that mix long and short form — something I haven’t really seen done well yet.
Most of my time went into figuring out how to resolve lexicon schemas. I wanted to build something that would scale to other lexicons in the future. I set up a system to pull schemas directly from the AT Protocol and validate records against them. I also built some debugging tools to help with this. The nice part is that schemas can be validated at runtime, and if something doesn’t line up or changes later, those tools will help me catch it.
Getting Leaflet to render wasn’t just about pulling the records — I also needed a way to translate the schema into actual components. Each block type in the schema (like text, headers, or images) maps to a component on my side that knows how to display it. I set up a generic rich text component that I use for both Bluesky posts and Leaflet, and I extended it so I can plug in different components based on the facets defined in the schema.
Leaflet support is close, and I’m hoping to launch it sometime this week. I’ll probably roll it out in a beta environment first to do some more testing, but I’ll share it out once it’s live.
Leaflet support on @atexplore.social is close! Mostly just some code cleanup to remaining.
ActivityPub experiments
At the same time, I started poking at ActivityPub. That’s something I’ve been wanting to try for a while. From the beginning, one of my goals with AT Explore has been to make it a data explorer for both ActivityPub and the AT Protocol.
Right now, it’s super basic — just pulling profiles and posts. But even that makes it clear how powerful this could be. The idea is to let people browse ActivityPub content right alongside AT Protocol content. Instead of treating them like separate silos, AT Explore could make them feel like different neighborhoods on the same map. I kind of think of it like a web browser, but for the open social web.
Something I’m experimenting with for @atexplore.social. AP Explore?
What’s next
This week I’m planning to wrap up Leaflet support and keep building out ActivityPub. If everything goes well, I’d like to launch Leaflet documents by the end of the week and also come away with a clearer plan for where I want to take ActivityPub next.
Longer term, I want to support more lexicons so AT Explore can surface almost any data type in a way that’s actually useful. Once ActivityPub feels solid, the bigger challenge will be putting the two side by side — letting you jump from a Bluesky record to a Mastodon post in one flow.
I’ll probably do a longer post soon that digs more into the technical details, but right now my focus is just on getting the foundations solid.