I want my AI agent (you know him, Eddie) to manage a calendar for me. Just not my private one. That one I only share with my girlfriend, which makes living together easier. While Eddie is also a part of my life, I wouldn’t entrust him with my calendar. At least I don’t want to find out what happens when he messes something up there. Additionally, he doesn’t need to know everything about me. Some things I’d like to keep to myself (and my girlfriend).
While brainstorming for a solution, Eddie proposed he could create ics files for me to import. You probably know these from booking an appointment at a barber’s, for example. Alongside the confirmation email they sometimes send you an event that you can add to your calendar by just clicking on it. That works fine, but you can’t do it that easily from a Telegram chat (at least on the iPhone). Super annoying, since Telegram is my main way of interacting with Eddie. But I liked the direction.
What if instead of serving me ics files directly, Eddie maintained one file on an external server that I subscribe to via my calendar app? Pretty much a public calendar. But we could make it more private by supporting basic authentication as well as random UUIDs for hard-to-guess URLs. I liked that idea, so we built it.
I first started working on it with Eddie on the Raspberry (me giving directions on my phone), but I soon moved the project to GitHub to review it on my laptop. Somewhere along the way I discovered that Eddie, for I don’t know what reason, had decided that this project should have no dependencies. I found that kind of funny for a JavaScript project, but also edgy, so why not.
That decision did lead to a lot of discussions about whether to introduce libraries for input validation, type generation, or just types in general, as well as something to generate an OpenAPI schema. You can take a look at the calfeed repository to see who’s won. In the end, what I really cared about were language-independent API tests and nice documentation. As long as they looked good, I didn’t want to bother with what the code looked like.1
But when it came to deployment, that zero-dependency policy paid off nicely. No build step whatsoever. Apart from some infrastructure like Caddy for TLS, you just run the script.
Anyways, I deployed it, gave Eddie his calendar, and subscribed to it on my phone. This works pretty well so far and I’m happy with the solution. But I’d like to develop calfeed further into a backend that lets AI agents manage calendars we humans can subscribe to. The whole thing started as a way to keep my calendar to myself, but the idea works just as well in the other direction. Eddie could maintain a public calendar with all music events in my city or sports events or whatever, and everyone who’s interested could subscribe to it.