We build our own tools and develop them in the open. The cvcpkg package manager and the tx.wtf platform are ours, built and owned outright — and around them we maintain forks and push fixes upstream to the projects everyone depends on.
The flagship is a package manager and registry for the scientific stack. The rest ranges from Direct Connect protocol software to a federated social platform to a Quake client that a live community still plays every night.
cvcpkg — hermetic scientific packaging
cvcpkg is a source-building package manager and registry for the hard end of the scientific stack — exact-arithmetic geometry, arbitrary-precision math, FFT, HDF5, BLAS/LAPACK, Qt, VTK, LLVM. SHA-pinned end to end, installable offline from a local mirror, and resolving a single dependency graph for the C++ and Python halves of a project at once.
700+ recipes, one graph, nine platforms
Scientific libraries in the browser
The part nobody else has done: the scientific dependency stack itself compiled for WebAssembly and WASI — exact-arithmetic computational geometry, arbitrary-precision arithmetic, FFT, HDF5, LAPACK, a full visualization toolkit and a GUI framework. These are builds you cannot get anywhere else, and they are what let native C++ scientific code run in a browser tab at all.
The whole stack ported, not just the app
Direct Connect — EiskaltDC++ and Verlihub
We maintain forks of EiskaltDC++ (the DC/ADC file-sharing client) and Verlihub (the hub server). On the client we removed the core library’s singletons outright rather than working around them, so the engine can be embedded, instantiated more than once, and driven from another process. On the hub we brought up a Python 3 plugin alongside the existing Lua and Perl ones. A Qt6 migration and the core-lifecycle work are open pull requests upstream.
Protocol software kept alive, and embeddable
A P2P core any application can use
Removing the singletons is what made eiskaltdcpp-py possible: the client core wrapped through SWIG into something arbitrary peer-to-peer applications can build on — a low-level module, a Pythonic client with event handlers, an asyncio wrapper bridging the C++ threads, and one unified protocol so the same code runs against a local engine or a remote one. Wheels ship for Python 3.10–3.13 on Linux, macOS and Windows.
A whole P2P engine, importable from Python
NMDCpb — protobuf, and file transfer behind NAT
A new protocol layer for a protocol from the 1990s. NMDCpb carries structured protobuf messages over NMDC, negotiated through $Supports so legacy clients are unaffected. It adds end-to-end encrypted messaging and hub-mediated relay channels: when both peers sit behind NAT and neither can accept a connection, the hub forwards the bytes, routing on a relay ID without ever deserializing the payload.
Direct Connect that still works behind NAT
Language models on a decades-old stack
Hub- and client-side LLM integration reached over an OpenAI-compatible endpoint, so an operator points it at a local sidecar or a hosted model with no code change — self-hosted by default, and private by construction for communities that would rather not send their chat to somebody else’s API.
Local or hosted, the operator’s choice
tx.wtf — federated platform and identity
Our own MIT-licensed federated social platform for communities that want to own their entire stack: posts and feeds, end-to-end encrypted messaging, per-user email and webmail, global search, and a full OpenID Connect provider with mandatory PKCE. We build it and run it in production — it is what signs users in to this very site.
Software we build, operate, and own
ezQuake
A fix merged upstream into ezQuake, the QuakeWorld client: a null check closing a potential race condition against hybrid servers. Small, but exactly the kind of thing that matters in a codebase two decades old with players on it tonight.
Merged upstream in ezQuake #1086
A live game server as a navigation gym
Ongoing work in the same fork, and deliberately listed as unfinished: reworking the engine so it can be driven as an agentic client, turning a live Quake server into a benchmark environment for our autonomous navigation research. A running deathmatch is fast, adversarial and genuinely dynamic — a far harder test than a synthetic scenario, and one that never plays out the same way twice.
A goal, not a shipped feature
Upstream first. A patch that lives only in our fork is a maintenance burden we have chosen to carry forever; a patch that lands upstream is one everybody stops paying for. So we carry forks when we must and push changes back when we can.
It is the same discipline we bring to client work: what we build for you should be maintainable by someone who is not us.
