This is the written version of a lightning talk that I brought to ATmosphereConf, an annual conference about the AT Protocol.
Hi! I’m Tim. Thanks for being here. This is my second ATmosphereConf, and I just drove up from Northern California and it’s been great. Everyone here, especially the organizers, has done a fantastic job.
This is a short presentation of a hack. I thought you might be interested in hearing about an unusual way that I use AT Proto, 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 job to make something new. That’s a lot to talk about, so I’m instead going to focus on one important problem: 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 one developer, a person with a laptop, and they all seem to add too much overhead for me right now.
So maybe 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.
- More importantly, while you’re searching for product-market fit, you might prematurely commit to things that aren’t good for you in the long term.
- And related to that, you might inadvertently become someone’s critical dependency!
That’s not 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, the Kubernetes CLI. 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 can be easily installed.
- Control who can activate them.
- Collect feedback and metrics on how the usage is going.
To do that, I just build and release Docker images, and I make all builds require a license key. My license key is just a JWT that identifies my user.
Now here’s the hack. I made it possible for people to generate their license keys themselves. All someone has to do is use AT Proto 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, the people who are willing to 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 Proto 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 someone wants to dig into my binaries and do that, OK (please don’t!). And finally, my users have to have an AT Proto account, but I don’t think anyone at ATmosphere 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!