30(ish) Days of Protocols
I have been doing 100 days projects once or twice a year since 2022, with varying degrees of success. I've written about the value of this practice so I won't go too deeply into it here other than to say that it remains the most effective method I've tried of "just getting things done". You commit to something and you do it every day, whether it's for 5 minutes or four hours.
So why am I doing a shorter version? Mostly because my last two attempts at a 100 days project failed. Both were writing, one private (journaling every day) and one public (blogging every day). The latter I don't feel terribly bad about since it was during the period where my mom died and I was planning a wedding, but the fact remains that since finishing my last successful hundred days project in early 2024, I haven't been able to see one through. Some of this is life stuff that was out of my control, some of it is intentionally being less hard on myself, and some of it is just a lack of motivation that may or may not be related to the prior two. At any rate, before committing to a hundred days project again, I thought I'd ease myself in with something smaller and see if this feels like a better form of daily practice for who I am and what my life looks like right now. I've done four successful hundred days projects and three unsuccessful ones, so I've proven whatever I had to prove to myself about it at this point. 30 is a nice round number that gets past the "do it for two weeks" mark without feeling like a slog.
That said, if I get to 30 days and am not feeling done, I'm giving myself the option of continuing for a while. I'll be traveling and (for at least a couple of days) sailing around the holidays, which will likely prevent me from getting to 100, but I could potentially get to 50 days without a forced break. We'll see!
Defining the practice
The goal, for the next 30ish days, is to produce a piece of code, art, or writing that explores how a given software protocol works in theory or practice. The primary focus will be the AT Protocol, but room is left open for the exploration of other protocols at my discretion.
Why protocols?
Over the course of doing 7 hundred days projects, I've noticed that the more specific the theme, the more likely I am to see it through and feel satisfied with what I've done. My two most successful projects, 100 days of Three.js and 100 days of Loop Studies, were respectively "use the same framework every day" and "iterate on the same theme every day". My least successful projects have both been "just write every day". In the words of Orson Welles, "the enemy of art is the absence of limitations". Well-defined boundaries in a project make it a lot easier to get things done - when you can make anything, you often wind up making nothing.
(Funnily enough, since I gave up on my last hundred days project I've started journaling every day - making it part of my morning ritual seems to work better than making it a hundred days project.)
Anyway, the trick to a successful days of X project for me is to be specific in defining it, but leave myself enough wiggle room that I can make something in 5 minutes on a day where I'm running low on time.
I had considered calling this "30 days of interoperability" or "30 days of coding" or "30 days of making stuff talk to other stuff" but in the end "protocols" feels like the right framing to me. I am mostly using this as an excuse to learn the technical underpinnings of the AT Protocol, the protocol behind Bluesky. Broadening it to protocols in general is just giving myself wiggle room to go off on research tangents or make something small when I'm short for time: e.g. learn about the USB protocol or spend some time playing with ActivityPub.
Generally: I think technical protocols are really interesting but remain the domain of the "hypertechnical". Even for a technical person like me protocols are often difficult to learn about and even more difficult to understand. These are the rules and regulations of how applications talk to each other, but they're usually obfuscated by frameworks, libraries, and decades of abstraction designed to make people like me not have to think about them when we want to build a website. My current mental model is thinking of them as the digital equivalent of, say, voltage limits or power line specifications: we don't think about these things in our day-to-day, but they touch everything, and if any component of the system doesn't follow them things catch on fire pretty quickly.
I love a challenge and I've always wanted to spend more time finding out how the protocols behind the technology I use on a daily basis actually work in practice. More than anything, I want to understand the "why" of it all. I have some abstract ideas of why ATProto works the way it does, or why federation struggles so much with having a source of truth, but I don't think I have any confidence that my understanding is correct.
Also, I'm more than a bit intimidated by doing this! That usually means it's something worth doing.
Why ATProto?
There are 2 sea changes happening in technology right now: AI and decentralization. I've spent plenty of time working on AI/ML stuff and have made my general ambivalence about the current bubble well known. I've spent years of my life writing, programming, and thinking about AI and I don't think I have anything left to say about it outside of the occasional blog post commenting on new developments. Frankly I'm burned out on the whole thing and the less time I have to spend thinking about it right now the better.
Decentralization, on the other hand, is relatively untrod ground for me (I've done my fair share of self-hosting and have set up a few federated services in my professional life, but have never really made it my primary focus for any extended period of time). Decentralization and the "dWeb" have become loaded terms thanks to the depredations of the crypto world but there are lots of interesting things happening in the broader space. The ideas of owning your own data and avoiding lock-in to a specific social network or other walled garden have always appealed to me, and while AI may be the thing on everyone's mind right now I'm optimistic that in 10 or 20 years decentralized protocols may underpin a significant portion of the web: general progress on the internet tends to be downstream of what programmers are interested in, and a lot of good programmers are trying to solve this problem right now.
ATProto specifically appeals to me primarily because, in the form of Bluesky, it's the only thing I've found actually usable so far. I played with Mastodon (built on top of ActivityPub) for a while, and have done some work with other AP-based services like PeerTube, but it's kind of annoying to use even for a technical person and seems near-incomprehensible for the non-technical as well. Bluesky has its own problems - some combination of its culture and the madness inducing effects of any form of social media - but it is significantly more usable than Masto and its ecosystem is more exciting right now. It seems easier to build things, more scalable, and generally like the stronger candidate to replace walled-garden social networks in the long run. It also, at the very least, doesn't have the insufferable Linux Reply Guy problem that Mastodon does.
On the other hand, it's more meaningfully centralized than Mastodon/ActivityPub, which gives me some cause for concern, but it does appear that since my last foray into the technical side of the two applications Bluesky has become, at least in theory, significantly more possible to self-host. It's also VC-funded - my understanding is that moving stewardship of the AT Protocol to a nonprofit entity is a work in progress, which would ease some of my worries - but right now it seems prudent to acknowledge that a lot of what's making its ecosystem better is that it has more money.
Regardless, though maybe through diving into protocols I'll find that I'm wrong about this, or that some other protocol is more promising, the "ATmosphere" is the most appealing ecosystem to me. Just the fact that its API is open and its code is open-source makes it a more promising target to build on top of than any of its predecessors. I don't think Bluesky is ATProto's killer app - "smaller Twitter" is not going to take the world by storm - but it's a solid proof of concept. Things will get interesting when the next social media sensation happens. Maybe this'll be hastened by US control of TikTok, maybe the increased censorship and right-wing indoctrination will continue to lead people off of major platforms, maybe creators will lead an exodus, or maybe someone will just invent a new kind of app that I can't conceive of yet. But once ATProto has a killer app I hope it'll slowly become clear how much value owning your own data has. There is plenty of risk here: corporate capture, government interference, or just the slow death that comes from a lack of adoption. But I'm hopeful that we can avoid that (open source is still around, after all) and regardless I'd like to do my part, however small, to push the adoption of decentralized protocols.