Internals
This page names the main building blocks so you know what you are running and where to look.
Two programs
Section titled “Two programs”Kaba Console (kaba) | Kaba Control (kabactl) | |
|---|---|---|
| Role | Desktop client | Engine and headless node |
| Language | JavaScript | Rust |
| Runs as | Desktop app | Child process of the client, a background service, or a container |
| Version documented | 0.146 | 0.87 |
The client bundles the engine. On start it copies the bundled kabactl into the user data directory if it is newer than the installed one, starts it, and waits for it to answer. If a healthy engine is already running, for example as a systemd service, the client uses it.
Client
Section titled “Client”| Component | Used for |
|---|---|
| Electron (Chromium) | Window, panes, rendering, the web platform |
| Lit | Every built-in UI and app, as web components |
| xterm.js | Terminal, with WebGL rendering and inline images |
| Ghostery ad-blocker engine | In-browser ad and tracker blocking |
| highlight.js, markdown-it | Code and Markdown rendering |
| uPlot | The header system-load chart and other small charts |
| esbuild | Bundling |
The client is organised as:
- Background process (
bg/): windows, frames and panes, the privacy layer, downloads, permissions, the tool loop, and the bridge to the engine. - Shell (
fg/): the header, pane chrome, omnibar, Kaba bar, menus, toasts and dialogs. Each floating surface is its own isolated view. - Built-in apps (
userland/): desktop, terminal, files, Hippocampus, settings, Projects, Toolbench and the editor, each served fromkaba://.
Every web page runs in a sandboxed renderer with context isolation. Pages on the web get no Kaba API; only kaba:// pages do. See SDK security.
Engine
Section titled “Engine”| Component | Used for |
|---|---|
| Tokio, warp, rustls | Async runtime and the HTTPS API |
| iroh and iroh-gossip | The peer mesh and public-service announcements |
| Arti | Tor, built in, including onion services |
| LanceDB and Apache Arrow | The memory vector store |
| SQLite via Diesel | Accounts, devices, policies, frames, history, settings, vault |
| llama.cpp | Model inference from GGUF files |
| Burn | LoRA training, on GPU through wgpu |
| whisper.cpp, ONNX Runtime | Speech-to-text and voice models |
| Tesseract | OCR of screenshots and images |
| Oxigraph | The tool-loop knowledge graph (RDF, SPARQL) |
Brave’s adblock engine | Ad blocking in the proxy |
| QuickJS | Runs the tool loop inside the engine on headless nodes |
| Argon2id, XChaCha20-Poly1305, BLAKE3 | Password hashing, encryption at rest, key derivation |
OCI runtimes (gVisor runsc, youki, crun, runc) | The command sandbox on Linux |
The engine is a Cargo workspace:
| Crate | Contents |
|---|---|
kabactl | The command-line front end, install, self-update, diagnostics |
kabactl-base | Paths, schema, shared crypto |
kabactl-store | The SQLite data layer |
kabactl-engine | Models, training, the vector store, voice, OCR, configuration |
kabactl-node | The server, proxy, vault, sandbox, terminals, cluster and tool loop |
kabactl-ontology | The knowledge graph |
Build features
Section titled “Build features”| Feature | In default build | Adds |
|---|---|---|
gpu | yes | GPU training and compute through wgpu |
voice | yes | Speech-to-text and text-to-speech |
ocr | yes | Tesseract OCR |
oci-pull | yes | Pulling container images without Docker (Linux) |
toolloop-js | yes | The tool loop inside the engine |
llama, llama-vulkan, llama-metal, llama-cuda, llama-rocm | no | llama.cpp inference and its GPU back ends |
multimodal | no | Image and audio input to the base model |
cpu | no | CPU-only build |
Release builds for each platform choose the back end that suits it. To see what a binary was built with, start the server and read the first lines of kabactl-server.log.
One tool loop, three hosts
Section titled “One tool loop, three hosts”The tool loop is a single dependency-free JavaScript module. The same file runs in the client’s background process, in the Projects page, and inside kabactl through QuickJS. That is why a headless node can run the same task the client can, with the same gates. Its tool catalog and the per-tool schemas are generated from one declarative source, and tests fail if the two drift.