What Witbitz Is — the platform
Witbitz is a trusted runtime for building collaborative applications where humans, applications, and autonomous AI agents work together safely, under explicit permissions. You build your app as a static website with a verifiable privacy policy, and Witbitz provides the runtime underneath. Read this first; the other docs go deep on each piece.
One line: a runtime for people and their AI agents to collaborate, where privacy is verifiable and humans keep the final authority.
1. The idea
The internet was built for users and applications. The next generation needs a runtime where people, apps, and autonomous AI agents collaborate — but safely, with permissions that are explicit and revocable, and with a human always able to say no. Today's AI ecosystem is siloing: every vendor wants your users, agents, memory, and work inside its own platform, on a backend it can read. Witbitz is the sovereign alternative — your Space holds your people, agents, and data, and nothing leaves it unless you allow it.
2. What the runtime provides
A collaborative app needs the same primitives over and over; Witbitz provides them so the app can be a thin static page:
- identity — who a participant is (see the link is the auth)
- permissions — who may do what (per-member capabilities; delegated, revocable authority)
- agents — hosting + running the AI that lives inside the app
- storage — the sealed, content-blind ledger + documents
- payments — metering + wallets for agent compute
- secure execution — the decrypt-once render where the AI acts, then drops the key
3. The three layers
Witbitz is three layers — this is its architecture, not a product stack:
- Interaction — how humans and AI meet. Today: live calls and async Spaces (more modes to come).
- The platform — a general-purpose app backend: the whole app flow, plus the AI that runs inside the
app. Exposed as the tenant-keyed
/v1API (API reference). - The app — a static page with no backend of its own, connecting only to Witbitz. To be precise: this is not "no backend" — Witbitz is the backend (layer 2: identity, storage, agents, execution, permissions, billing). The proposition is narrower and more honest: you trade an arbitrary, app-specific backend for a single, constrained, inspectable platform one. That's what makes an app's privacy verifiable — there is exactly one trust surface and it is auditable, not that centralized infrastructure or trust dependency went away.
Everything happens in a Space: a self-authenticated room whose identity, members, and keys live in the link, not a central account server (room-link-auth).
4. The two guarantees (why it's safe)
- Verifiable privacy — the double blind. A Space's data is sealed ciphertext at rest under a key the platform never holds. As long as the compute runs the declared program, the operator is blind to the data and activity — and so is the app's own owner. Neither can read the users' content. Because the app is a backendless static page talking only to the audited Witbitz API, its whole data footprint is declared and its privacy is checkable, not promised. (the double blind).
- Human authority. Agents never own authority — they receive it. An agent proposes an action, the runtime evaluates policy, an authorized human approves or edits, then it executes — explicit, limited, revocable, audited. (delegated authority).
5. Built on Kibitz (what's reused, precisely)
Witbitz runs on the open Kibitz engine, and the relationship is exact — worth stating so nothing is overclaimed:
- The live call is Kibitz (a pinned dependency, rebranded). That path gets Kibitz's full peer-to-peer gate — account-free rooms, the join gate, cert-bound OIDC, end-to-end-encrypted media — by running the engine.
- The async Space is witbitz's own. It is a turn-based, content-blind HTTP service (no WebRTC, no OIDC, no cert-binding). The only thing it borrows from Kibitz is the invite-token wire format, reimplemented byte-compatibly for per-member identity (room-link-auth §4).
So: for the engine (calls, mesh, cert-binding, the agent-in-a-call protocol), the canonical docs are Kibitz's
— see the "engine" links in /llms.txt. For witbitz's own layer (async Spaces, the platform
API, the double blind, the Bridge), these docs are canonical.
6. The first app: Spaces
The first app built on Witbitz is Spaces — a multiplayer ChatGPT: a shared room where people and an AI collaborate together, with tools that render as live widgets and a room that persists. Try it: witbitz-spaces.pages.dev.
7. What you can build — the topologies
Spaces connect in different shapes; the valuable apps are the ones where the shape is the product:
- One governed room — an org's AI serves a person (tools + governance; the org can't read individual sessions). Customer service, a bank advisor, telehealth intake.
- Pro + AI with a private back room — both serve a client, and confer privately. Teacher + AI, doctor + scribe, lawyer + paralegal.
- Two sovereign sides — the Bridge — each side preps privately, they meet in a shared room. Negotiation, M&A, procurement, mediation. (the Bridge).
- Hub & spoke — a person (or case) at the center, several orgs bridge in. Care coordination, eldercare.
- Many players — the Spaces app. Group planning, a family council, community rooms.
- A traveling personal agent — your Space + agent joins others with scoped permissions. Personal assistant, shopping concierge.
8. Access
The /v1 platform API is invite-only during private beta (tenant keys). The Bridge is an early protocol preview.
Email hello@witbitz.chat.
9. Where to go next
- The Space link is the auth — membership, keys, per-member identity, the double blind (deep).
- The Verified Room — one definition for live P2P, async reads, and server-verified writes (crown-jewel).
- async Spaces · the double blind · identity lifecycle · delegated authority · the Bridge · API reference
- The engine (Kibitz) deep-dives — linked from
/llms.txt.
Machine-readable source: platform.md · every doc in one fetch: llms-full.txt · verify →