Hub devlog: taking stock of the beta
A quiet fortnight on Hub, so a look at what is actually working, what is not yet, and how I want to describe the post-quantum handshake.
I have not touched Hub in eleven days. The time went to the Elite Dangerous tools, and I do not feel bad about it: the last Hub commit was the licence change, the tree is clean, and the suite is green at 666 tests on the portable build and 672 on Windows, with warnings treated as errors. So instead of a change list, this is a stock-take. I find it useful to write one down every so often, because the picture in my head drifts from the picture in the code.
What I would demo today
Text, voice, video and screen share all work. Voice is Opus over UDP through my own relay - no WebRTC, no Electron, which was the whole point of the rewrite. Every media packet is sealed with AES-256-GCM under a key derived per sender, and the part of the header that has to stay readable for routing is authenticated as well, so nothing in it can be changed without the packet failing to open. Screen share goes as high in resolution and frame rate as the GPU encoder will take.
Certificate pinning has a proper “it changed” path now. First connection shows you the fingerprint and asks. If it ever changes, you see the old one, the new one, and get asked for your password before anything is re-trusted. I wanted that to be a conversation, not a login failure with no explanation.
Direct messages are end-to-end encrypted. Channels are not yet. I am not going to claim otherwise anywhere, and the project page here says exactly that. The blocker is a design decision, not code: what happens to the channel key when someone leaves. Until I have an answer I am happy with, channel E2EE stays on the list.
Permissions are channel-level overwrites, and bots start with no access anywhere - they get let in per channel, with posting and reading as separate switches. Memory behaves: history pages in and out in both directions, idle memory is reclaimed every minute, and a long session sits around 38 MB managed. Jump-to-latest drops a bloated session from 364 MB to 266 MB.
The post-quantum handshake, said carefully
The hybrid ML-KEM-768 plus ECDH session key is implemented, tested, and a server owner can require it. What has not happened is a real client on real hardware completing the handshake end to end. My CI machines cannot do it, and the one laptop I own that can has not been put to the job yet. So every mention of it stays “beta, in testing”, and I will keep it that way until I have watched the skipped tests turn green on real metal.
One number I keep reminding myself of: the ML-KEM code is 651 lines, and a third of that is policy rather than cryptography, because the key encapsulation itself is a .NET 10 library call. The security work that cost me real effort is elsewhere - roughly 2,800 lines of authenticated encryption, at-rest encryption and media key schedule, and about 3,000 lines of tests for it, because in that code a mistake does not crash anything. It just quietly encrypts wrong.
Also
The repository is Apache 2.0 now, with a NOTICE file and a short trade mark policy. Fork it under your own name if you like; keep the notices, and the “Bahuckel” name stays mine.