The Big Picture

Read this first. It holds the shape of the whole system on one screen. Everything else in this book is a zoom-in on a piece of what follows.

What the Xe Computer is

The web has apps but no computer. In a browser you can open an app, but you cannot really install it, own its identity, own the trust chain that says it is what it claims to be, compose two apps together, or sync your own state across your own devices. A native operating system gives you all of that — install, identity, trust, composition, sync — but it is closed: the vendor owns the enclosure.

Xe Computer is the missing layer between the browser and the OS. It makes web apps first-class citizens of a machine the user actually controls. The one-line north star is “a universal app package manager for the web” — but sovereign: you can inspect it, fork it, and leave it without losing anything.

The wider bet: within a few years something will act in every person’s name across their whole digital life. The only question that matters is whose side it is on. The platform answer is the closed super-app. Xe Computer is the open, user-sovereign alternative — the super user agent. What that commits us to is spelled out in Mission & principles; read that next, it is the lens for the rest of the site.

How it fits together, in one pass

Every one of your devices runs its own Xe Computer instance. There is no central hub — devices are peers that sync to each other. On each device:

• A small Boot Service wakes the runtime on demand, then lets it sleep. Nothing heavy runs when you are not using it.
• The runtime stands up a local plane bound to 127.0.0.1:5454. Every app you have — installed locally or served by one of your other devices — appears at a stable web address like http://<app>.localhost:5454. Because browsers treat *.localhost as a secure origin, each app gets exactly the isolation the web already provides. No per-app packaging required.
• Behind the plane sits an origin router — a small, pinned web server (workerd, Cloudflare’s runtime for serving code) whose routing table is generated from your installed-app records, never hand-edited. Apps that need a real backend reach an app engine (a hidden container/VM layer) through a socket the engine itself publishes.
• Prism is our shell: a super-app that frames each app in an isolated Controlled Frame (a web embedding surface stronger than an <iframe>), composes them, and journals every action an agent takes. darc → Reagent is the resident agent layer that acts through Prism, with the boundary, grants, and audit trail we build around it.
• Xenon is our browser — a fork of Helium (itself a de-Googled Chromium) that makes these apps work without developer flags. Until Xenon ships, any Chromium-family browser runs the same apps via a flag recipe.

Devices connect as peers over iroh (a peer-to-peer transport that dials a device directly by its public key). One device can serve an app to another, byte-for-byte; a phone companion is a remote control and consent surface, not a sync peer. Trust runs top to bottom from our forge and a signed catalog — install checks the signature and content hash before anything runs; the console witnesses the receipts.

The whole system, one diagram

Edge and node labels mark what is proven today versus designed-only. Legend: ● proven (verified in the 2026-07-18 build-and-run matrix) · ◇ designed-only / blocked (has a design of record, not yet demonstrated end to end).

flowchart TB
  legend["● proven (2026-07-18 matrix) · ◇ designed-only / blocked"]:::note

  subgraph DIST["Forge + Distribution — Agent54 (cluster-internal, d/065)"]
    FJ["Forgejo forge — origin of record (d/007, d/013)"]
    CAT["Signed catalog<br/>Ed25519, serial-anchored (d/067)"]
    FJ --> CAT
  end

  subgraph DEVA["Device A — Xe Computer instance (macOS)"]
    direction TB
    BSA["Boot Service — on-demand wake (d/053)"]
    PLANEA["Local plane 127.0.0.1:5454<br/>origins http://&lt;app&gt;.localhost:5454 (d/100)"]
    RTA["Origin router = workerd, pinned + launcher-managed (d/078)<br/>route type: Origin / backend-proxy / container-origin* (d/103)"]
    ENGA["App engine — smolvm / colima / docker (d/051)<br/>backend via engine unix socket (d/094)"]
    FWDA["peer forward :5198 — internal (d/102)"]
    BROWA["Xenon (Helium fork, IWA-enabled, d/061)<br/>—or— stock Chromium + flag recipe (d/057)"]
    PRISMA["Prism — super web app / shell (d/063, d/075)<br/>Controlled Frames + agency ladder (d/082, d/091)"]
    DARCA["darc → Reagent — resident agent (d/062)"]
    CONA["Console — witness: receipts + update ledger (d/064)"]
    BSA --> PLANEA --> RTA
    RTA --> ENGA
    RTA --> FWDA
    BROWA --> PRISMA
    PRISMA -->|frames plane origins| PLANEA
    DARCA -->|acts through| PRISMA
    CONA -.->|reads journal ◇ open seam| PRISMA
  end

  subgraph DEVB["Device B — Xe Computer instance (Linux)"]
    PLANEB["Local plane :5454"]
    RTB["workerd router"]
    FWDB["peer forward :5198"]
    PLANEB --> RTB --> FWDB
  end

  PHONE["Phone companion — remote client + consent surface,<br/>NOT a sync peer (d/042, d/062)"]

  CAT -->|"install: verify sig + digest ● proven"| RTA
  CAT -->|install ●| RTB
  FWDA <-->|"iroh peer serving ● byte-identical (P-184)"| FWDB
  RTA <-->|"peer-sync v1: metadata only ◇ designed (d/068)"| RTB
  PHONE -->|"plane binds + iroh direct ● (P-202)"| DEVB
  PHONE -.->|"in-frame render ◇ blocked on d/104"| PRISMA

  classDef note fill:#f5f5f5,stroke:#bbb,color:#333,font-style:italic;

What is proven vs designed-only

Drawn from the build-and-run matrix in status/2026-07-18-night.md; the full table lives in the proving matrix.

How to read this site

This book is a zoom ladder. Each part descends one level: big picture → layers → subsystems → open questions. You can stop at any rung.

1. The Big Picture (you are here) — the whole system on one screen.
2. Part I — Mission & Vision — the why and the rules to judge every design against: the mission and sovereignty litmus, and the decisions ledger recording what we chose and why. Read Part I before Part II — it is the lens.
3. Part II — The Stack — the layers, bottom to top: transport & identity, the serving plane, peer serving, the app model, engines & backends, the shell (Prism/Xenon), devices, and the agent layer. Each layer chapter opens with a short “What is X?” primer, so you do not need to know iroh, Isolated Web Apps, or Controlled Frame going in.
4. Part III — Design Reviews — a critical read of each layer against the litmus: what is strong, what is thin, where the seams are.
5. Part IV — The Design Frontier — the honest gaps. Where the mission demands something no decision covers yet (movable memory, exit-without-loss, multi-user), it is recorded here as first-class work, not hidden. The External Review (sol) section that follows Part IV holds the six verbatim memos from an independent frontier-model critique; the frontier’s External review input lines point into them.
6. Part V — Emerging Specs — protocol and format candidates as they firm up.
7. Appendix — a glossary, a repo & link directory, and the proving matrix (the full ●/◇ table).

A note on honesty: proven and designed-only are kept visibly separate everywhere, and decisions still awaiting Luke’s sign-off are marked PROPOSED wherever they appear. If something is aspirational, the text says so.