Hive: Build Log

Another big structural for Hive. 723 files changed, 90,471 insertions, 132,463 deletions against upstream main at the fork point. SQLite is gone. PostgreSQL with pgvector is the only storage backend now. No migration path as this still isn't a real code base. The previous setup had Arc<Mutex<Connection>> contention, spawn_blocking wrappers everywhere because rusqlite isn't async, and client-side cosine similarity computation that should have been happening in the database all along.

This security pass wouldn't have been possible without first cleaning up the pedantic lint issues and expanding test coverage. Auth was optional, password hashing was SHA-256, and the GCRA rate limiter had a bug where it never actually rejected requests, this one I stumbled upon by accident while writing end-to-end tests. The nested Result<Result<_, NegativeOutcome>, InsufficientCapacity> return was only being checked at the outer level so every request that should have been limited was getting waved through. Not ideal. Auth is mandatory now but the first-time user experience isn't great. You get a 503 on everything until you use hive security set-password on the server side to manually create a user. Query parameter tokens were previously being used and have since entirely been removed. Putting credentials in query params is a very easy way to get live credentials in logs, referrer headers, and browser history. Password hashing moved to Argon2id, SHA-256 is not acceptable for user credentials. There's now a real user system backed by the database with per-user API keys (hive_ prefixed so they're easy to spot if they leak). CLI persistent authentication similar to other tools like the AWS CLI, and first class support for remote servers both in the config and via a --host flag.

I stumbled across another group that also forked OpenFang called LibreFang. Their README hints at some kind of drama that I couldn't find as the only real call out is "open governance" and "merge-first PR policy". I looked for a blog post or discussion or specific rejected PR that triggered it but I'm certainly curious. They seem to be trying to maintain feature-parity which at this point I don't think I'll be pursuing for the most part. We've already diverged far too much but I'll be watching both for good ideas to incorporate. It seems like they've added more hands, internationalization support, and redone the front end. More power to you folks! Good luck and I'll keep an eye out.

There are a lot of agent harnesses out there. So why build another one? I've spent a lot of time in this space. I built several small agent systems in both Rust and Python, tried most of the popular frameworks, ran models from all the major providers and a bunch of open ones, experimented with custom LoRA layers and spec-driven task systems. Every setup taught me something about where things break down and I kept notes along the way. What I wanted wasn't exotic. A system that runs on my hardware, manages agents as durable long-lived processes, connects to the communication channels I already use, and enforces real security boundaries between agents and data. Capability-based access control, taint tracking, domain isolation, per-process network filtering. These are all well-understood ideas with decades of prior art. The agent ecosystem just hasn't prioritized them yet because everyone's working on different problems.