An engineer with 15 years across hardware and software. I got tired of expensive closed-source tools that rarely work properly, so I build the open alternatives myself — self-hosted, no telemetry, no accounts, no strings attached.

Beta testers welcome. Hub and Diag are in closed beta with no public download yet. If you want to try one, open a ticket and say which project and which platform, and I will send you a build.

Text and voice for communities that would rather not hand their conversations to someone else's servers. Built around a simple rule: the server should learn as little as possible.

• Nothing is collected. No analytics, no profiling, no logs sold on. Not even an email address is required to sign up — there is no email field anywhere in the server.
• End-to-end encryption, rooted in a recovery phrase. Every member gets 18 words (the kind crypto wallets use); their keys come from those words and never leave their own computers. Direct messages are always end-to-end encrypted. A community's owner can switch it on, for good, per text channel, voice channel, board and whiteboard, and for the channel names themselves: there, messages, files, link previews, reactions, polls and calls are sealed by the members' apps, and reports go sealed to the admins alone. Who may read is a membership list the owner signs, so an account the server invents on its own gets nothing. If someone's key ever changes, you are warned, and you can compare a safety number with them (/verify).
• What the server still sees. Who has an account, who is in which community and channel, who sent something when and how large it was, who is in a call, and members' addresses — as in every system of this kind, Signal and Matrix included. Channels and calls the owner has not encrypted stay readable to whoever runs the server (encrypted on its disk, with a key it holds). On your own box, that is you. An owner who encrypts a channel later can delete what the server can still read from before.
• Post-quantum key exchange — beta, in testing. On top of TLS, the client and server agree a session key with a hybrid handshake: ML-KEM-768 alongside classical ECDH. ML-KEM is a NIST standard rather than a research curiosity — FIPS 203, published 13 August 2024, built on the Module-LWE problem — and NIST's own claim for it is carefully hedged, so it is quoted here rather than improved on: “At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.” Believed, not proven, and that is exactly why this is a hybrid and not a replacement: the session is only weaker than a classical one if both halves are broken. What it aims at is harvest-now-decrypt-later — traffic captured today and kept in the hope that quantum hardware will open it later. It needs a platform that provides ML-KEM: OpenSSL 3.5+ on Linux, or Windows 11 24H2 / Server 2025 and newer. Anywhere else the connection is plain TLS, exactly as before, and says so rather than pretending. Server owners can require it, which locks out clients that cannot do it — off by default, and deliberately awkward to turn on.
• Designed so the hub you run is the only party that holds your community's data. No third-party service sees members, chats or calls; what the owner encrypts is unreadable even to the hub.
• Run it on your own box or your own VPS. If you would like a hand, get in touch: I can help you set up a VPS and walk you through how it all works. The server stays yours. I don't run it or hold its keys, so whoever operates it, meaning you, is the only one who can see what the points above say the server can.
• Want to test it? There is no public download yet. Ask for a beta build — say which platform, and I will send one.

Currently a ground-up rewrite in C# / .NET 10 / Avalonia, with over 1,400 tests behind it. It was called BahuckelChat until September 2026. The original JS/TS Electron build never hit the performance targets I set for it, so it has been retired: bahuckel-chat-electron-deprecated.

• Performance — the C# rewrite is holding around 0.3% CPU and 160–185 MB of RAM while in a call.
• Screen share — any resolution and frame rate, including custom ones. You are limited only by how fast your GPU can encode frames and by your bandwidth; drop the resolution or the frame rate if you want the overhead lower.
• Extras — KLIPY GIF support (bring your own API key), plus live shared Kanban and whiteboard channel types.
• Networking — works out of the box when TCP 3847 (chat) and UDP 3848–3849 (voice and video) are reachable. Behind NAT, forward those ports, use ZeroTier, Tailscale or a similar VPN, or run it on a VPS. A plain Cloudflare Tunnel is not enough on its own: it carries chat, but not UDP, so voice, camera and screen share will not connect through it. If voice cannot reach the server over UDP, the client tells you so instead of leaving you in a silent call.
• Long channels stay light — a busy channel is not held in memory in one piece. Messages page in and out around you as you read, in both directions, and the client hands memory back on its own while you are idle.
• It tells you when a certificate changes. Self-hosted servers are pinned by fingerprint on first connection. If that fingerprint ever changes, you get the old one, the new one, and a password check before anything is re-trusted — not a login failure with no explanation.
• Small comforts — middle-click free-scroll, jump-to-latest, and a scrollbar you can actually hit.

Plugins — features you don't want are features you don't pay for. The owner of a community can upload a plugin and enable it, and it becomes a new channel type sitting alongside Text, Voice, Kanban and Whiteboard. Nothing ships enabled, and nothing you have not enabled is ever downloaded, loaded or drawn, so the parts you don't need cost you no disk, no memory and no CPU — which is the point. It is also how integrations with other software get in, enterprise or otherwise, without any of it being welded into the app for everybody else.

• The server never runs plugin code. It stores the package, validates it, and hands it out to members; it will not execute a DLL, spawn a process or evaluate a script from one. The client loads it, in a context of its own that can be unloaded again, and a plugin that throws gets an error panel rather than taking the app down with it.
• Nothing runs without asking you first. A plugin is a program: it runs inside the app, as you, with the app's access to your computer. .NET cannot fence code in, and this does not pretend to. So before a plugin runs on your machine you are shown what it is, who added it and its package fingerprint, and asked; the answer is pinned to that exact package, and an update asks again. A plugin that reaches for the obvious escapes — starting processes, native code, raw sockets, loading code at run time — is refused before you are even asked. Only allow plugins from people you trust.
• Coming, from me: graphs and charts as a channel type, and a BahuckelDiag integration — so a channel can carry your fleet's health directly: which machine, when, where, and why it flagged something, in the same place your team is already talking.

Health monitoring for physical Windows and Linux servers that tells you something useful instead of drawing graphs at you.

It reads temperatures, SMART and NVMe attributes, ECC/WHEA machine-check errors, fan behaviour and system event logs, correlates them, and produces a plain-language diagnosis: which component is probably failing, why it thinks so, and what to check — with the evidence listed and conservative confidence, because "replace the DIMM" is not something you should say on a hunch. Runs as a single local dashboard or a small fleet reporting to one hub.

It also ships an AskAI agent, running on a local model, over your network, or through one of the big three APIs (Anthropic, Google, OpenAI). It can simulate incidents, read the live machine state, and propose diagnostic or recovery commands. How that is kept under control:

• Nothing runs until you click Allow. The model can only propose a command; you see the exact line before it executes, and the request expires if you leave it sitting.
• Approval is re-checked at execution time, against the current settings — not against whatever was in force when the command was proposed.
• Commands are scoped to a folder you choose, and any line naming a path outside it, or reaching for a system-changing verb, is refused.
• Every run is written to an audit table, so you can see afterwards exactly what was executed and when.
• Web access is off by default. With it on, the agent still refuses to fetch loopback, private-network, link-local and cloud-metadata addresses.
• The local model runs in its own process, so a model crash can't take the dashboard down with it.

Python · FastAPI · SQLite — in development, private for now. Beta testers with real hardware to watch are welcome: ask for a build.

A bundle of companion apps for Exobiology, Travel, Trading and Colonization — the tedious parts of the game, made quick, in a clean and deliberately simple interface. Most of these are coming to GitHub soon; an early colonization tracker is already up as edct.

• EDEXO-Colonize — a smarter way to track every open colonization project. Route planning that optimises for your actual cargo hold, plus commodity prices and availability. Auto-discovery of components through the Spansh API, and live journal following that records market values as you visit stations.
  • Chrome extension — a helper for Inara, not a scraper. It never crawls and never fetches anything by itself. The app hands you a link to the commodity you are after; you open that page yourself, and the extension adds a couple of buttons to the top of it. Press one and it saves what is already rendered on your screen into your local database. Nothing runs in the background, no page you did not open is ever touched, and Inara serves exactly the one request your browser was going to make anyway.
• EDEXO-Compare — tired of flying to a planet, scanning it, and finding nothing worth a credit? This holds data from over 100,000 planets with biological life and compares them against the planet you just finished an FSS on. Not a deterministic answer — some species (the damn bacteria) share conditions with plants that actually pay — but far better than memorising the conditions for every species yourself.
• EDEXO-Compare-Feeder — an add-on for Compare that lets you feed in your own scans. Data stays local. Share it if you gather an impressive amount; credit appreciated, never required.

C# · Avalonia · Python · FastAPI · JavaScript · TypeScript · SQLite

Also on here: slick-tire-converter — converts street tire sizes to race slick sizes.

Questions, VPS hosting, a beta build, or just to say hello: bahuckel.com/contact, or email support@bahuckel.com.

If something here saved you a headache or some time, and you like the idea of software that will never collect, use or sell your data:

_{Self-hosted by default. If it collects, uses or sells your data, I didn't build it.}

_{Opinions and projects here are my own, built in my own time outside working hours, and do not represent my employer or its values. Everything I build has one purpose: to give people a functional, free alternative to popular software, without turning them into the product.}