# Witbitz > Witbitz (https://witbitz.chat) 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 — identity, > permissions, agents, storage, payments, and secure execution. It is built on the open Kibitz engine and inherits > its account-free, link-based room model. Witbitz is **three layers**: (1) **interaction** — how humans and AI meet, today live calls and async Spaces; (2) **the platform** — a general-purpose app backend that carries the whole app flow and the AI that runs *inside* the app; (3) **the app** — a static page with **no backend of its own** that connects only to Witbitz. To be precise this is *not* "no backend" — Witbitz **is** the backend; the app trades an arbitrary per-app server for one constrained, inspectable platform, which is what makes its privacy *verifiable* (one auditable trust surface, not zero). Everything happens in a **Space**: a self-authenticated room whose identity, members, and keys live in the link, not a central account server. The platform is **content-blind** — a Space's data is sealed ciphertext at rest, so as long as the compute runs the declared program, neither the operator **nor the app's own owner** can read the users' content (the "double blind"). Agents never own authority; they receive delegated, revocable authority, and a human keeps the final say (propose → approve → execute). The first app is **Spaces**, a multiplayer ChatGPT. This file is a map for language models. Each page below links to its clean Markdown (`.md`). The full text of every doc inlined into one file is at https://witbitz.chat/docs/llms-full.txt. ## Start here - [What Witbitz is (portal home)](https://witbitz.chat/docs/): the trusted-runtime idea, the three layers, the double blind, the featured Spaces app, and what you can build (the app topologies). Read this first. ## Docs (deep dives, code-synced) - [What Witbitz is — the platform](https://witbitz.chat/docs/platform.md): the read-first overview — the idea, the runtime services, the three layers (interaction / platform / app), the two guarantees (double blind + human authority), exactly what's reused from Kibitz vs witbitz's own, the first app, and the app topologies. - [The attested tier](https://witbitz.chat/docs/the-attested-tier.md): **built and independently verifiable, NOT yet serving traffic** — the room key generated inside AWS Nitro hardware and bound into a hardware-signed attestation, so sealing to it is sealing to a measured image. Browser-side verification (pinned AWS Nitro root, own X.509 chain walk), PCR0 reproducible from published source, PCR8 derivable from the published signing certificate rather than taken on our word. Also states plainly what it does NOT buy: model egress, metadata, behaviour-vs-measurement, and the audit cost of a large image. - [The Verified Room](https://witbitz.chat/docs/room-link-auth.md): **the crown-jewel model** — one definition of *who is in a room and who said what* that works with **no server (true peer-to-peer)** AND with a **server that verifies but cannot read**. All of Kibitz's mechanism (signed invites, the signed manifest, join-gate modes, RS256 OIDC + DTLS cert-binding, agent-key admission, capabilities, verified host) and how the SAME definition applies across three verifiers — a peer (live call), any reader (async read), and a certified-ephemeral function (async write) — each with a mechanism-for-mechanism Witbitz async counterpart. The nonce-binding insight: bind the credential to the DTLS fingerprint (live), the signing key (async identity), or a server-issued challenge (async presence). Deeply technical; read this to understand Witbitz auth end to end. - [Verify it yourself](https://witbitz.chat/docs/verify.md): reproduce the enforcement in your own terminal — token-less `poll`/`turn` to an email-gated Space → `403 not_authorized`, an open Space → `200` (the control proving the 403 is the gate, not a bad key). Honestly scoped: this checks the **admission gate**, NOT content-blindness at rest or declared-program-in-use (those are the signed certificate + attested tier, designed not issued). The page is built to grow — the certificate/attestation checks land here as they ship. "Verifiable at the gate; trusted in use." - [The Space link is the auth](https://witbitz.chat/docs/room-link-auth.md): the membership + key-model + double-blind foundation the verified-room credentials sit on — key possession (`mkCommit`), the k-of-n key model, the E2EE ledger + decrypt-once render, per-member entry signatures compatible with the Kibitz room link, and blind-safe short links. (For the full authorization gate see The Verified Room, above.) - [The owner rule](https://witbitz.chat/docs/the-owner-rule.md): **BUILT (opt-in, behavior-neutral)** — how an APP OWNER gets authority over admission without breaking content-blindness, turning "the link is the authority" into "the owner is the authority." An owner-SIGNED App Policy (a ladder of tiers: open/member/gold, each = an admission test + capabilities + limits) is mandated onto every room at creation through a credential only the owner holds, and enforced in three independent places (the render verifies the signature + gates each turn; a cleartext marker guards the blind read paths; peers verify against a pinned owner key). Tier comes from SIGNED sources (IdP claims / grants) so no self-promotion; the ladder doubles as the pricing surface. Registration federates to the owner's directory (Witbitz runs no accounts). Orthogonal to [the attested client](https://witbitz.chat/docs/the-attested-client.md) (person vs code). - [Identity, lifecycle & recovery](https://witbitz.chat/docs/room-link-auth.md): the hard, honest questions a bearer-link model must answer — member removal (writes cut now; reads cut by epoch re-key), historical vs future decrypt, key rotation, device-loss recovery (user-held, never operator-held), replacing a compromised identity without rebuilding the Space, and exactly what metadata the platform can still see. Marks shipped vs designed throughout, and introduces the **Witbitz Companion** — a device-side runtime that moves keys off the copy-around URL into the device keystore, with user-side rotation/recovery + install-once notifications (roadmap). - [The Companion](https://witbitz.chat/docs/the-companion.md): an **optional** native runtime — demoted from pillar to convenience. The essentials it was meant to add already work with **no app**: content-free push on an installed PWA (reach-me), a hardware-backed **passkey** + user-held recovery (keys), and local decrypt in the verifiable client — with [Sealed Spaces](https://witbitz.chat/docs/the-double-blind.md) the path to the key never reaching the server. A Companion would still add more reliable notifications and a Secure-Enclave keystore; nothing on the roadmap depends on it shipping. - [The attested client](https://witbitz.chat/docs/the-attested-client.md): **server seam BUILT; native clients not** — the missing symmetric half of server attestation. You cannot attest browser code, so offer (opt-in) a native shell that bundles the SAME reproducible web bundle INSIDE a hardware-attested app (App Attest / Play Integrity-or-Keystore / TPM+WDAC), loaded LOCALLY not off the network (a network-loading WebView / Android TWA attests the shell but not the logic = theater). Attestation freshness-bound per action; "only attested clients may join" becomes a server-verified admission condition. Honest split: integrity attestable on all platforms, shipped-binary reproducibility Android-clean / iOS-partial / Windows-DIY. - [Async Spaces](https://witbitz.chat/docs/async-spaces.md): the agent as a function, not a server — the sealed ledger, the decrypt-once render, content-blind poll (etag over ciphertext), the ops, idle ~ $0. Live in prod. - [The double blind](https://witbitz.chat/docs/the-double-blind.md): verifiable privacy — ciphertext at rest (platform blind) + a backendless static app (owner blind) + the certify-the-footprint north-star; shipped vs designed. - [The live call](https://witbitz.chat/docs/the-live-call.md): the OTHER trust model — WebRTC DTLS-SRTP between browsers, relay-by-default here (FORCE_RELAY, so the relay sees metadata but never content), signalling as the one attackable party, and the safety code that would verify it — currently not exposed in Witbitz Call's UI. Read this before conflating a call with a Space. - [Delegated authority](https://witbitz.chat/docs/delegated-authority.md): humans keep the final say — propose, approve, execute + a sealed append-only audit; the invariant that no action runs without an approval. - [Enterprise & on-prem](https://witbitz.chat/docs/on-prem.md): run the ENTIRE runtime in the customer's own boundary, off our cloud — every external seam is one env switch (model / object store / records / secrets / IdP admission), defaulting to hosted behavior when unset, so it's the same reproducible image. Two tiers (VPC + air-gap); `AIRGAP=1` makes it zero-egress (CSP names no external host, tools refuse) and the signed cert's meaning inverts to supply-chain proof the customer verifies on their own hardware. - [Platform API — the /v1 surface](https://witbitz.chat/docs/api-reference.md): tenant-keyed JSON API — auth (secret/publishable keys + capability tokens), the envelope, idempotency, and the surface (agents, collections, items, artifacts, sessions, credits, tenants). The OpenAPI is canonical. - [The Bridge](https://witbitz.chat/docs/the-bridge.md): governed collaboration between sovereign Spaces (the cross-org frontier) — the three-space model, the five invariants, key epochs, the live ops, native-or-external parties. Early protocol preview. ## API - [Platform API — OpenAPI (production)](https://api.witbitz.chat/v1/openapi.json) · [full design spec](https://api.witbitz.chat/v1/openapi.full.json) · [discovery](https://api.witbitz.chat/v1/): tenant-keyed, JSON over HTTPS. Agents, collections, sessions, wallets, ratings; a keyless render page for published content. Invite-only during private beta. - [The Bridge protocol — OpenAPI](https://witbitz.chat/docs/bridge.openapi.yaml) · [normative spec](https://witbitz.chat/docs/bridge-protocol.md): governed collaboration between sovereign Spaces (the forward-looking, cross-org frontier) — a shared Space N parties join, party-signed + content-blind, verified against per-party keys. Early protocol preview. ## Try it - [The Spaces app (demo)](https://witbitz-spaces.pages.dev): a multiplayer ChatGPT — a shared room where people and an AI collaborate, with tools that render as live widgets and a room that persists. No install, no account. ## The engine (Kibitz) Witbitz runs on the open Kibitz engine. The **live call IS Kibitz** — that path uses the deep-dives below by *running the engine*. The **async Space** is witbitz's own (turn-based, content-blind HTTP); it ports only the Kibitz **signed-invite** identity format (see the link-auth doc above), NOT the OIDC/cert-binding path. These Kibitz docs are canonical for the engine — witbitz does not duplicate them: - [Kibitz map for LLMs](https://kibitz.chat/llms.txt) · [everything in one fetch](https://kibitz.chat/llms-full.txt) - [Architecture](https://kibitz.chat/docs/architecture) — the room model, the transport planes, the composable engine. - [Threat model](https://kibitz.chat/docs/threat-model) — who can see what; the agent surface. - [Verification](https://kibitz.chat/docs/verification) — "the link is the verifier": the join-gate methods (the source we ported for async). - [Cert-binding](https://kibitz.chat/docs/cert-binding) — how an OIDC token is bound to the DTLS cert (the LIVE-only mechanism async does not use). - [Agent protocol](https://kibitz.chat/docs/agent-protocol) · [Agent platform](https://kibitz.chat/docs/agent-platform) — how an AI agent perceives + acts in a call, and the capability/consent model. - [Offline mode](https://kibitz.chat/docs/offline-mode) — same-Wi-Fi rooms via a LAN hub. ## Contact - hello@witbitz.chat — API access (private beta), general, and security.