This is the written version of a lightning talk that I brought to ATmosphereConf, an annual conference about the AT Protocol.
Thanks for giving me a bit of your attention! This is my second ATmosphereConf, and it’s now my favorite tech event of the year. I love being here in Vancouver; there’s so much to learn about and do here and such great salmon!
This is a short presentation of a hack. I thought you might be interested in hearing about an unusual way that I use the AT Protocol, and that it might trigger ideas for things that you might do with it.
I’m a software developer, and I recently left a corporate tech job to make something new. That’s too much to talk about here, so I’m instead going to focus on one important problem that I faced: How can I get feedback on early versions of my work?
You might have heard of products that help with this. ConfigCat, LaunchDarkly, and PostHog are three that I show here. These are fine, but right now I’m just a solo developer, a guy with a laptop, and they all seem to add too much overhead for me right now.
So I’ll bet you’re asking, “why not just open source it?” I’ve done that for other projects, and it has some downsides.
- If you’re doing something new, you might be teaching your competitors or their coding assistants how to solve the problems that you’re solving.
- You might prematurely commit to features that aren’t good for you in the long term.
- And related to that, you might inadvertently become someone’s critical dependency!
That isn’t far-fetched. It happened to me when I was working at Google. One of my projects accidentally became useful to the Kubernetes team and became a critical dependency of kubectl. That sounds great, right? But I wasn’t on the Kubernetes team, and as I moved around Google, none of my managers appreciated the time I spent maintaining my project. Eventually it was just a tax on my time, like lots of open source projects become.
Here’s what I decided to do instead:
- Release binaries that people can easily install.
- Control who can use them.
- Get feedback and metrics on how that usage is going.
To do that, I just build and release Docker images of my tool, and I make all builds require a license key. My license key is just a JWT that identifies that user and that’s signed by a private key that I keep secret.
Now here’s the hack. I made it possible for people to generate their keys themselves. All someone has to do is use ATProto to log into my website and press a button. But who gets to do that? I want to only include people that I’ve approved (basically, people who talk to me before trying it), and rather than maintain a list of members, I make the membership list be the accounts that my project account follows. If @agent.io follows you, you’re in!
I really like this. Because I’m using AT Protocol identities, my beta is agnostic to all of the various corporate identity systems, so no one can be mad that I’m using one of their competitors. Also, it’s super-easy. I didn’t even add a lexicon. And it’s public! Anyone can see who’s in, so people can easily learn who else is interested in IO.
But this might not be right for you. If you want to keep your users secret, you’ll need to keep your own list. Also, it’s hackable. If you want to muck around in my binaries and do that, good for you, but please don’t redistribute my work. And finally, my users have to have an AT Protocol account, but I think no one at ATmosphere really thinks that’s a problem.
So again, thanks for your attention! Here’s a list of things that I enjoy chatting about, so if you see me around and don’t have a starter topic, pick any of these!