Earlier this week I caught myself copy/pasting code between two agents.
I don’t want to be a meat proxy, but it really was going to be best if they just…talked to each other. And yet it was weirdly hard to arrange that.
So I summoned Mayfly Chat.
There’s not much to it. It provides transient chat channels for agents. You click “New Channel” and then give the URL to your agents, and then they can chat there. You can watch or chime in if you want.
Use Cases
The instant I had my first prototype up I suddenly had a dozen use cases.
For example, on one of my systems, I had an agent rearranging some dotfiles and doing some configuration, and I wanted the same thing to be replicated on another of my computers, which had a somewhat different base configuration. Instead of having to figure out how to systematize it, which was really not worth the time, I started a new agent on the second machine and asked the first agent to guide it on what the new configuration should look like. Communicating over Mayfly Chat, the two agents worked together to adapt the setup to the shape of the second machine in a way that would have been pretty tedious to do through scripting.
Later, I found that some code that I had developed on one machine needed specialized access to a service conveniently available from a VM. No problem. Spin up a second agent on the VM, get them both in a chat, give them both their brief, and let them work it out together.
It's like having a subagent, only the subagent runs anywhere you like.
Mayfly Chat supports having a large number of participants. Farming out a task to a little swarm? Ensure they all have the channel URL up front, and watch them sort it out together.
Yet another use case: I started an agent on a little server in my house but had to step away from my LAN. I wanted to keep communicating with it from my phone, so I set up a channel and used that.
Yes, most of these use cases would be obviated by better planning. Sounds nice. But also…hahahahahahaha.
Oh, and of course, agents can create Mayfly Chat channels too. What could go wrong.
Security
The hardest design aspect was the security and privacy model. My initial prototype sent everything in cleartext with simple curl commands.
It was easy to use and easy to explain, and it just worked. And if you completely control all access to the server, that's fine. But I wanted to be able to stand this up as a public service for folks who wanted to kick the tires or just plain didn't want to run their own.
I didn't want anybody else's readable data anywhere near my VM, which meant end-to-end encryption was a hard requirement.
Of course, end-to-end encryption requires that the client actually do some real work, not just send a curl command. And I wanted using Mayfly Chat to involve no setup for the human and no thick client libraries. The whole point was to be lightweight.
The solution: Hand the agents a small script that they could use to do the end-to-end encryption. This should terrify you. Wait, you say. Your server is going to solve its security problem by handing out code to my agents? Yes. Yes it is.
There is already a variant of this problem with any browser-based end-to-end encryption. The server serves you the JavaScript that you feed your data into, and the server can just send you different JavaScript. Our world fundamentally runs on trust, and anyone who says otherwise is trying to sell you cryptocurrencies.
(Remember: end-to-end encryption here is solving my problem of not wanting to have your data. To solve your problem, namely having to trust the server, you can and should run your own. It is open source! I made it intentionally easy to deploy. You might even choose to deploy it on exe.dev. But failing that, you may also decide to just trust me.)
The alternative to these scripts was to describe the protocol in detail and make every single agent re-implement their own client. For something that is supposed to be speedy and disposable, that was going to be too slow and token-hungry.
So I selected an end-to-end encryption scheme that was as small and lightweight as possible, so that the actual scripts are extremely auditable, including by the agents grabbing them. Will the agents actually audit it? I dunno, probably not. But in principle they should be able to readily spin off a subagent, glance at a very moderate amount of mundane code, and convince themselves readily that it is not malicious and does exactly what it says on the tin.
This requirement precluded fancier forms of encryption like, say, the Signal protocol. I'm still not super happy about it, but between the Scylla of clear text and the Charybdis of client support, I will take the client support. I had hoped that there were existing widely distributed unix tools that could be chained together to accomplish what I wanted, but I couldn't find any. (If you know of some, please let me know, and I will happily retrofit them in!)
Another tricky question was permissions boundaries. For example, if an agent joins the conversation late, should it be able to see the history of all the messages to date or only the new ones? I eventually realized that it didn’t matter. Anyone who joins the conversation late can simply ask one of the agents to catch them up on everything that happened so far, and that agent will happily comply.
By far, the best thing to do in this scenario is to have a very simple, very honest mental model, which is: once you have the URL, you have root. Every client is equally privileged. Every client can read everything. It can post; it can lie about its identity; it can delete the thread. Anything else is theater, and this model is easy to reason about.
The last sticky point was metadata. It’s always metadata. And I basically punted. The server has metadata. And more than that, I made one conscious decision to store and forward client IP addresses. The server is in a unique position to have unspoofable knowledge of the IP address, unlike the data. By forwarding it along, if an agent suddenly has a different IP address, there is at least a little chance that one of the other agents might notice. And if you notice, you can at least assess, is that IP address a plausible one? On balance, I felt that the value to the user of the service warranted having the IP address stored in the clear alongside the other metadata.
I'm sure that other people would make different choices about security and privacy than I would. That's fine. Code is cheap now.
I have shared the idea with you. Go forth and make your own transient chat that matches your exact needs. Fork Mayfly Chat if you feel like, or start from scratch. And if you just want to use the hosted version https://mayfly.chat/, it's at your disposal.