ATmosphere Conf is coming up - March 26th to 29th in Vancouver BC. Lately I've been seeing announcements from folks who will be attending and speaking. This is great! The conference is shaping up to be pretty awesome.

I can't attend due to prior personal commitments. I'm bummed - I've been increasingly participating in atproto coding. And Vancouver is close enough to Seattle where I'd be able to drive up for the conference. I don't attend many conferences, but I'm certain I'd enjoy this one.

In an alternate universe, I'd be able to attend. And in that universe I would propose a talk. This post is that talk.

Main point

I guess the main point I want to drive home is the following:

  • The atproto developer ecosystem is very approachable

What do I mean by approachable? For me, it's when a topic is easy to understand and discuss, the community feels welcoming, and the topic continues to hold your attention. atproto has been (and continues to be) all of those things for me. I started tinkering with development in atproto over a year ago - and it's just as interesting to me today as it was on day one.

Below are some reasons why I feel atproto is approachable. ⬇️

Reason number 1 - You can get started quickly

It doesn't require a huge lift to start working with atproto. You can fire up your favorite shell and connect to an XRPC endpoint with a tool like curl. I think many folks start by making a call to an endpoint like resolveHandle or getProfile. I started with some PowerShell scripts that connected with the APIs. It's exciting the first time you get a response back from an endpoint.

Reason number 2 - As you make progress, the difficulty incrementally increases

Once you get comfortable in the space, you can start increasing the difficulty of the tasks. They each become fun, new challenges. I think my progress went something like the following:

  • "Let me try and call the XRPC endpoint." (calling XRPC from shell)

  • "Ok, let me download a repo." (writing that response to disk)

  • "What's a CAR file? Can I decode that?" (DAG-CBOR decoding)

  • "Now that I have a DAG-CBOR decoder, can I read the firehose?" (firehose parsing)

  • "I've gotten pretty far with decoding - can I encode DAG-CBOR?" (DAG-CBOR encoding)

  • "What's this thing called MST?" (creating MST)

  • "Now that I have all of these pieces, would it be possible to implement a PDS?"

And I have a list double that size with more things to try.

Reason number 3 - There are a variety of places to get a foothold

Another great thing is that there are many places to get a foothold. Some people are drawn to infrastructure, like PDSs, relays, and AppViews. Other folks want to build apps on top of the protocol. You can create a feed, or a labeler, or self-host infrastructure. There are many paths to choose from, and you don't necessarily need to stick to one path.

Reason number 4 - A lot of the work happens out in the open

Folks working on atproto - whether that be for Bluesky PBC or otherwise - tend to develop out in the open. There are GitHub repositories for much of the Bluesky code and discussions. Developers chat about it in places like Discord or on Bluesky. You can go to these places and ask questions, and more often than not you get helpful answers. And in these places, members of the community (even Bluesky PBC) invite the contributions from folks. I remember reading Call for Developer Projects and thinking "this is a great way to grow a developer community". A more recent example is this article about permissioned data.

Reason number 5 - The documentation is solid

I find that I continually go back to the documentation to look things up. The XRPC endpoints have a reference, the protocol itself has various specs, and related tech also has documentation, like DAG-CBOR. There are a lot of resources for someone wanting to jump in.

Any obstacles?

Although atproto is approachable, there are some obstacles that I've needed to overcome. Let's walk through those. ⬇️

Obstacle number 1 - Not everything is documented

Sometimes you just have to test things and figure it out. While implementing a PDS I've hit several issues:

  • subscribeRepos reconnects: firehose events for deletes were causing consumers (relays) to immediately disconnect and reconnect. But the reconnect would read the same firehose event, which would disconnect and cause an infinite loop of reconnects. It took me a while to figure out that the structure of my firehose event was slightly wrong.

  • Disappearing videos: videos posted by my PDS would disappear from the Bluesky CDN after 2 days. Like above, this was caused by a slight difference in the firehose event data structure. I didn't discover this until I compared the DAG-CBOR generated by the reference PDS vs. my own PDS.

  • Signature validation on the new relays. One weekend I was traveling, and my PDS started acting up. Many of my posts wouldn't appear on Bluesky. But I saw the posts in my repo, and in alternative AppViews. It turns out that the new relays were deployed on that same weekend, and the new relays verified signatures more strictly. I'd argue it was "more correctly", but it was a change nonetheless. (shout out to the team for helping me with that: self-hosted PDS posts intermittently appearing in app · Issue #312 · bluesky-social/pds)

Obstacle number 2 - Development is fast-moving

The protocol is under active development. In a way this is great, because they are making progress. But sometimes it feels like it's difficult to keep up the pace with development. As someone building an alternative PDS, I like to make sure I stay up to date on things. An example of this is permissioned data coming into the PDS - I'm unsure how that will impact my own PDS.

In the end, is it worth it?

ABSOLUTELY. I have a long list of things I want to try next, and I can't wait to tackle them.

atproto is a great tech stack. And a great tech community.