If you had asked me a year ago what I would be up to now, I would have guessed leading one of the major appviews on the network, or working on my own PDS implementation, maybe even an atproto SDK.
I actually tried all those things, but they were more like experiments along the way that was paved by my increased obsession with that other "side" project: PDSls.
THE MOTIVE
I was already developing apps on this protocol, and like many, I ended up creating all kind of garbage records in my repository for testing purposes. Similarly, sometimes we need to troubleshoot record deletion, and back then there was no convenient tool to delete records, you had to write a bunch of lines of code. So I made this:
I never shared it publicly, few people knew it existed, and as matter of fact, it was a very modified fork of cleanfollow. Very lackluster UI, but it worked for that specific purpose.
And what pasta said stuck with me:
(Futur did end up doing an atproto browser with a file explorer UI: https://safari.futur.blue/)
And then there was the trigger:
The bullet went straight to my nerd brain...
THE EXECUTION
I immediately got started on it, and according to Discord logs, I already had the name picked from the start.
PDSls because it's like using the ls command on a PDS to list its content. Back then, it was centered around this one feature, and it wasn't even possible to search a DID or AT URI. This was the next step, I wanted to have feature parity with atproto-browser.vercel.app.
This is what PDSls looked like exactly a year ago. (October 30th 2024)
THE AFTERMATH
In the first few months, there was always something to iterate on. Deleting/editing/creating records, relay streaming, backlinks, querying labels... Development was quick. Nobody to report to. It being a SPA means it was entirely client-side and left me with no backend to worry about. The scope was established from the start: it was a dev tool, meaning any feature had to answer a simple question: is it useful for atproto development? I didn't concern myself with a pretty UI or flashy gimmicks. Eventually everyone was using PDSls.
(A bit of glazing doesn't hurt...)
THE LEGACY
It's not the only atproto explorer (I've come to use this term over "browser" to differentiate it from the original one made by Tom Sherman), it wasn't even the first one, but it's the one that had a very committed NEET working on it for a year now. However, I have limited experience with web development, and in general, not much of a computer science background behind me. I like to say "I didn't know what async/await meant a year ago" but that's a bit of an exaggeration. I think this showed in many ways, but since there was nothing better, and I always tried my hardest to fix issues, improve the UI, redesign the site (oh so many times), all of this for free, no one had a reason to complain.
It also gave some the ability to present aspects of the protocol, turning this arcane dev tool into a learning tool. I always felt a lot of pride seeing this happen, which is why I always made it a priority to avoid clutter in the interface so it was easy to screenshot and use in slideshows.
To summarize my ethos:
it's a tricky balance but i love the challenge of making a dev oriented tool feel simple and easy while not compromising on features and informations
Recently I introduced lexicon schema documentation:
This is another example of me looking at the state of tooling in the community and convincing myself one day on a whim: "I can do better". We still need proper documentation sites, but PDSls can at least give you a way to peek at lexicon schemas as they are developed without having to parse the rather terse JSON.
I'm still determined to avoid scope creep, bloating the project with unnecessary dependencies, or drastically change its architecture:
It will remain a client-side app, for the purpose of development, it's important. You can actually use localhost from https://pdsls.dev.
That said, it wouldn't hurt to have it look a bit more polished, and include more features to not only assist developers, but also anyone who is interested in learning about the protocol, and to give a more direct peek at the data without the intervention of downtimes or moderation.
That last one has left me upset a few times... I mentioned it in another article:
BUT I don't believe much in auteur theory so if you want to use PDSls to bypass the nuclear block or takedowns, go ahead, I will not stop you. I just write the code, and I am not liable for potential consequences using it. The beauty of open source means anyone can fork it, host it, and who cares what the person behind it thinks. (You apparently since you made it this far into this blog post)
A part of me wishes I knew more when I started this project. I would have done quite a few things differently, and the codebase would likely be a lot more organized. But I can't learn any other way, I love getting my hands dirty, and figuring it out as I go. For this, atproto is the best community to be a part of because there is so much to do, even someone like me was able to contribute. I like where I'm at now, I hope it's only the beginning.
I don't think I have much to add. I just wanted to write a little retrospective on what constitutes most of my work for the past year. I search "pdsls" and "pdsls.dev" everyday and it makes me happy to see it used. Thank you for the support, the donations, and all the kind words I have received.