Starting a new journey 4 min read
ATProto

Starting a new journey

By Benjamin Listwon
Starting a new journey Post image
A journey of a thousand miles begins with a single step.
—Laozi

I'm not great at taking the easy path.

My own personal stack overflow

Let me back up a a bit. Before deciding to build a solo project on the AT Protocol, I started by saying this over on Bluesky:

Bluesky post that reads: Benjamin Listwon ‪@benjaminlistwon.com Realized I gotta get back into the rhythm of shipping web projects daily/weekly again,  or I'll never get the big one out the door. So I dreamed up a little project to work on this week. Goal is to push something live daily. Stay tuned.  #AlwaysBeShipping February 24, 2025 at 9:17 AM
Me, about to enter the Dimensional Rift

I thought I was going to hammer out a simple little way for people to share little insights they've had in their life, career, hobby, or just in general. This was inspired by asking why can't everyone—not just celebrities—have something like Wild Card with Rachel Martin? Role models and inspirations come in just about as many varied forms as there are people on this earth.

But then—duh, duh, duh—I stumbled on the AT Protocol, and I knew I had found a way to make something much bigger. I knew immediately, I could help make a positive difference for folks, while also maybe providing a non-icky alternative to some existing platforms out there.

And once I had that realization I knew I'd have to build some parts of my app in Node or Go to make the most use of the SDKs and other tools that Bluesky and the AT Proto devs had already built.

Theeeen, I realized that I didn't really know a lot about any of the above, so I'd have to undertake some rapid learning of distributed systems, running Node at scale, consuming the firehose without falling over, yadda, yadda.

And, of course, I thought out loud, "I should document and share this journey of discovery." But my creaky, decades-old, disused-since-2016 blog won't work, so I'll need some fresh blog action. Hence the search for and rapid rollout of this very Ghost blog.

You get the idea, I hope.

Okay, let's go!

Insert sound effect of a record scratch here

The first thing you'll notice on your ATProto journey is that there is a lot of documentation written by the fine folks who have worked on Bluesky and the initial AT Protocol implementation, but not a lot of "How do I do X?" type of content out there.

You can run down the official Github repos for the protocol packages, visit the app showcase, dig into protocol implementations in other languages, run through the Bluesky tutorials or build this little app, all of which are very helpful, but ... it's a lot.

A girl, wearing a nun's habit, and with melted chocolate all around her mouth says, "That's too much."
It's a lot.

DIDs and NSIDs and BSONs? oh my!

The second thing you'll notice is that there is a lot of new jargon (i.e. WTF is a DAG-CBOR?) and lingo in this brave new world, and sort of a working assumption that a brief explainer will do.

This might be okay for various acronyms, but if you're new to a lot of the concepts of federated or distributed architectures like this, you may have a lot of questions about how to transfer your existing ideas to these new ones.

A concrete example. The idea of a Personal Data Store (PDS) is more than just understanding the words that make up the acronym. To be sure, AT Proto folks like K-NKSM have explained a lot of the advantages of the role that a PDS plays, but again, each area of the protocol is its own deep dive.

What the heck will my architecture look like?

If you're a pre-worrier like me, all of this makes you ask questions like:

  • If I build a service, how might I auto-provision PDSes for users?
  • Can I rely on the one that Bluesky provides for already registered users?
  • If my service gains traction, will they get upset if I add a lot of data to those PDSes? Will they make me migrate them? Can I even support or afford that?

All of this quickly spirals beyond just the PDS. Like, do you have to support registering and storing DIDs for new users, or do you send them to Bluesky? Are you now an identity provider? What cloud provider should I even select for all of this, based on how much each resource consumes?

So, where am I at then?

After a couple days digging into the AT Protocol, well, scratching the surface really, a whole lot more began to click for me. So naturally, a quick sketch occurred ...

A diagram, hasstily sketched in a sketchbook, of a possible architecture for building some quick AT Protocol-backed apps.
This should work, right?

My goal in the next couple of weeks is to write a lot of the boilerplate code that I will need to "talk" to the various parts of the protocol.

From there, I think I will be able to start building lots of little "toy" applications on top of the protocol, and accessible to anyone who has an identity through Bluesky today.

My goal by the end of March is to be able to share something with folks at the ATmosphere Conference here in Seattle, or at least be able to converse with folks in a semi-sophisticated manner!

And if all of that pans out as expected, then I am going to start generating more substantive apps on top of the protocol throughout the spring. (I even formed a small LLC to make cool things under, but more on that in a few days!)

Lastly, I've been keeping notes the whole way, so I am going to begin transcribing those into little mini-posts here under this tag, so that anyone else embarking on this journey has a few breadcrumbs to follow, and hopefully they can get up and running even faster on this revolutionary platform.

See y'all around!