Protocols

Kaba has three communication layers:

Client to engine, on one machine: HTTPS and a WebSocket to kabactl on localhost.
Inside the client: the kaba:// scheme that serves the built-in apps.
Device to device: the mesh, a set of named streams over encrypted QUIC connections between peers you own.

Nothing in this list depends on a cloud service. The only outside infrastructure is a relay, used when two peers cannot reach each other directly, and you can run your own.

Client to engine

The client starts kabactl server and talks to it over HTTPS on port 28832, verified against the engine’s own certificate. Browsing and terminal traffic goes through the engine’s SOCKS5 proxy on port 28833. Both are described under services.

The kaba:// scheme

Built-in apps are pages served from inside the client under kaba://. The scheme is registered as secure and standard, so these pages behave like HTTPS origins, and it is the only place the SDK is available.

URL	App
`kaba://desktop/`	Desktop
`kaba://terminal/`	Terminal
`kaba://files/`	File explorer
`kaba://hippocampus/` and `kaba://kaba/`	Hippocampus
`kaba://settings/`	Settings
`kaba://kaba-projects/`	Projects
`kaba://toolbench/`	Toolbench
`kaba://search/`	Kaba Search
`kaba://editor/`	Source editor

The full list is in the URL reference.

The mesh

Devices in a cluster connect with iroh. Each node has a key pair; its public key is its node ID and its address. Peers are found by key, not by DNS name or IP address, and every connection is authenticated and encrypted end to end between those keys. There is no certificate authority to trust and no inbound port to open.

Connections are direct when the network allows it. When it does not, traffic passes through a relay that forwards encrypted packets it cannot read. The default relay is https://relay.kaba.dev; see network settings to change it.

Each kind of traffic has its own named protocol on the connection:

Protocol	Carries
`kaba/cluster/v1`	Membership: joining with a ticket, the peer list, eviction.
`kaba/intro/v1`	Introductions between peers and key exchange.
`kaba/rpc/v1`	General requests between peers.
`kaba/sync/v1`	Replication of shared state between your devices.
`kaba/folder/v1`	Folder synchronization (Kaba Sync).
`kaba/fs/v1`	File operations on a peer: list, read, write, rename, remove.
`kaba/fsstream/v1`	Streaming file contents, for previews and media.
`kaba/fswatch/v1`	Change notifications for a peer’s folders.
`kaba/pty/v1`	Terminal sessions on a peer.
`kaba/exec/v1`	Sandboxed command execution and container management on a peer.
`kaba/infer/v1`	Inference: a prompt goes out, tokens stream back. Also lists a peer’s adapters.
`kaba/train/v1`	Training: a corpus goes out, progress streams back, the adapter returns.
`kaba/exit/v1`	Exit-node tunneling of proxy traffic.
`kaba/expose/v1`	Traffic to an exposed service.

Who decides what

The peer that does the work enforces its own rules. A node only serves inference if accept_remote_inference is on, only trains if accept_remote_training is on, and only runs commands if enable_peer_exec is on. For inference, the adapter that answers is the peer’s choice unless the request names one that the peer has.

Requests carry a signed, timestamped envelope. A peer rejects envelopes more than 60 seconds old, so device clocks need to be roughly right.

Exposing services

A node can publish a local host:port to the mesh:

Private services are reachable only with an access token, which can be rotated.
Public services are announced on a shared gossip topic and indexed by their page metadata, so they can be found from Kaba Search. This is the “.kaba web”.
A service can additionally be published as a Tor onion service.

Supported protocols are http, https and tcp. Create one from Hippocampus → Services → Expose.

Leaving the mesh

Traffic that leaves your devices for the internet goes out through the proxy of whichever node is the exit. On that node it can be sent over Tor, globally, per pane, or for selected domains. See privacy.

The tool loop contract

Model-driven work runs as a tool loop: a bounded sequence of steps, each one a call to a tool from a fixed first-party catalog, under budgets and with cancellation. The catalog is code. Policies and overlays can remove, re-describe, scope and order tools, but nothing in data can add a capability the binary lacks. Kaba does not load third-party tool catalogs.

The same loop runs in the client and inside kabactl, so a headless node behaves the same way. See projects & tool loop and the file formats reference.