The Curse of the Developer

The Curse

Part of being a developer involves inspiration hitting at suboptimal times. For me, inspiration comes in waves: I hyperfixate on a problem until I whittle it down to a solution. Over the years I have learned to lean into this and ride the wave rather than try to flatten its arc. Well, it is currently 2:45 in the morning, and I can't stop thinking about what I did wrong in my AI interview chatbot project I built into this site.

Since this site is pretty small, I monitor the analytics pretty closely. While 11 people have visited the interview page, 0 have initiated an interview session with my agent. It's possible the sample size is too small to be significant, but I think it's a good indicator of a problem, and it's keeping me up at night! So where did I go wrong implementing x402 into my site?

The Good

One of the key aspects of the crypto industry that draws me in is the self-sovereignty of money. A litmus test in the real world on one's willingness to partake in Web3 often stems from one's acceptance of the existing financial system. My initial descent into madness crypto was trying to make sense of the GameStop saga. A story for another day, but the learning for me was the importance of observability in the financial system.

Because of the preamble above, I chose to allow users to bring their own wallet into my interview feature. To me, this approach is preferable, as I do not have to trust the developer to manage a wallet but instead allow another party to specialize in it and deliver a signed payload to the site for payment. Objectively, I still think this is fine, and maybe even better, but it creates friction.

The Bad

A key component of x402 is the ability to require payment at the API endpoint level. This is powerful in allowing microtransaction-level, stateless access to an API, but means in the context of a chatbot that the user must pay for every message they send. Having to sign a transaction for every message is a terrible UX, so I went with the JWT approach, granting a user access to the API for a limited time. This somewhat defeats the purpose of using x402 to gate the endpoint, since I’m now limiting user inference with a time-based JWT instead.

The Ugly

I was concerned enough about the UX to bypass the technology's main advantage, and not concerned enough to integrate a managed wallet into the site to streamline onboarding and access. Not only did I make it harder for the average visitor to get started using the agent, I also bypassed the key part of x402 to do it. It is now a cumbersome experience for the user and more difficult for the endpoint to manage inference costs, not that anybody was using it anyway.

Redemption?

Where do we go from here? The most obvious path is to implement a managed wallet into the site. A user will be able to onboard with as little effort as loading a dollar or two with Apple Pay. As the usage of the bot increases, it will transact in the background and decrease the remaining balance. I can imagine some interesting quality-of-life improvements, like seeing the wallet balance and cost per message, that would not have made sense previously. I would still like to allow for self-managed wallet integration, but it will be an optional way to interact with the feature at the user's own UX peril.

Now that I know what to rebuild, maybe I can finally get some sleep.