Mission & principles

This chapter is the lens. Every layer, review, and open question in the rest of the book is meant to be read against the commitments set out here. If a design cannot be checked against the sovereignty litmus below, that is itself a finding.

The mission: the super user agent

The name carries the whole thesis in two old meanings:

• super-user — in the Unix sense, root over your own computing. Full authority on your own machine.
• user agent — in the original web sense, software that acts for you, on your behalf, under your direction.

Put together: a piece of software that acts across your whole digital life, with full authority, and is unambiguously on your side.

The premise is simple and near-term. Within a few years something will act in every person’s name across their entire digital life — booking, buying, corresponding, remembering, deciding. That much is not in question. The only question that matters is whose side it is on. The dominant answer being built today is the closed super-app: an agent inside a vendor-owned enclosure, assembled out of open pieces (Chromium, Electron, webviews) but sealed so the user cannot see in, change the rules, or leave with their data. The counter-move — the mission — is an open, user-sovereign delegation layer.

The missing-layer thesis

Stated concretely: the web has apps but no computer. A browser can open an app but cannot let you truly own its install, its identity, the trust chain that vouches for it, the composition of one app with another, or the sync of your state across your own devices. A native OS has all of those, but closed. Xe Computer is the missing layer between the browser and the OS — it gives web apps first-class citizenship on a machine the user actually controls. The working north star, from docs/state.md, is “a universal app package manager for the web”: install, run, trust, compose, and sync web apps, on infrastructure you own, on any of your devices.

The sovereignty litmus

The mission is not a slogan; it is an operating constraint with six clauses. Every design in this book is checked against them, and where current code fails a clause, that is tracked as debt rather than glossed over. An agent is yours only if you can:

1. Inspect what it sees — you can look at the context, inputs, and state the agent acts on.
2. Fork its permission model — you can change the rules of what it may do, not just toggle vendor-provided switches.
3. Bring your own models and keys — you are not locked to one provider’s model or one provider’s credentials. (This is a live litmus test: hardcoded model IDs anywhere in the code are a known violation and tracked.)
4. Move its memory — your state and data are portable, not held hostage.
5. Audit its actions — every action leaves an inspectable trail.
6. Leave without losing everything — exit is possible without forfeiting your data, your identity, or your history.

Three of these six are only half-met today, by our own honest accounting, and they lead Part IV — The Design Frontier: movable memory (app data is single-home; sync moves metadata, not the data inside apps), exit-without-loss (xe export exists as intent, not a proven whole-machine round-trip), and audit (some grant/trust journals sit outside the hash-chained audit log, so the console cannot yet witness them). The site names these plainly rather than implying the litmus is fully satisfied.

Power Design

Power Design is the conduct standard. It binds all output of the system and the team’s own conduct — it applies to the racks and the fleet, not only to user interface. An agent that touches a machine’s baseboard management controller is held to a stricter audit standard than one that restyles a page. Its clauses:

• Honest — no performed confidence; name uncertainty; if something is aspirational, say so.
• Inspectable — state is visible and provable, not asserted.
• Zero-trust — the system assumes nothing and proves its own state rather than trusting that it is correct.
• Audit + undo — anything done unattended leaves an audit trail and a persistent undo.
• Doesn’t belittle — the user is treated as capable; no condescension.
• Minimal — the smallest surface that does the job.

One binding rule reaches all the way down into copy: every failure string ends with an action. A user (or a reviewer) who hits an error is always told what to do next.

Calm vocabulary

The product uses a small, canonical vocabulary. It matters here because words carry the architecture — the names below are used precisely throughout the site, and the distinction between an app’s install level and an agent’s rung (the two axes below) depends on keeping them straight. The full list lives in the glossary; the load-bearing names:

• Xe Computer — the cross-platform runtime (home: xe.computer). Not “the launcher.”
• Xe Computer Boot Service — the on-demand wake mechanism; zero resident processes. Not a “daemon,” not an “agent.”
• Xe Computer console — the management UI. xe — the CLI.
• Xenon — our Isolated-Web-App-enabled Chromium fork (the browser), not the runtime. (Repo names like xenon-* are historical.)
• app engine — the substrate layer inside Xe Computer that runs backends. The concrete engine names (colima, lima, docker, smolvm, WSL2) never appear in user copy.
• apps — web apps on the spectrum below. “Install an app,” never “install a bundle.”
• super web app / super user agent — an app granted fabric-level capabilities; interchangeable terms, and never framed as “privileged.”
• Reagent — the coming rename of darc. Luke and Jan execute the rename; new copy should not bake “darc” in. Until then this site writes darc → Reagent.
• Folknet — the community compute fabric that backs the fleet.

A style note the site inherits from doctrine/vocab.md: we describe design work with calm words — probe, stress-test, critical review — never the adversarial register.

The two capability axes

This is the most important conceptual tool in the system, and the easiest to get wrong. There are two separate axes, and they move independently.

Axis 1 — the install spectrum (a property of the app)

What is this app granted? Defined by d/076. Every surface Xe renders is a web app on some level of one spectrum — there are no cliffs, no separate “native app” class:

Axis 2 — the agency ladder (a property of the agent’s action)

What is my agent doing on this surface, right now? Defined by d/082 and revised in d/091. It runs from doing nothing up to being the shell itself:

nothing → allowed / denied / shielded → observed → enhanced → mutated → controlled → driven → composed / generated / delegated → super user agent

A few rungs to know: shielded means the agent actively guards a surface (a first-class state — permission denied is not an error, it is a valid outcome); driven means the agent operates a live surface over the Chrome DevTools Protocol (the same wire protocol browser automation uses); generated composition means the agent reads pane A and pane B and produces a new artifact C. Every rung is consented, receipted, and undoable.

The two axes move independently. An app’s install level and the agent’s rung are orthogonal — a plain L1 app can be driven or composed by your agent; a super L3 app can just sit there being observed. No new named level joins either axis without a decision. Keeping these apart is what prevents the system from collapsing back into “privileged native apps vs sandboxed web pages.”

The two-tier app model

This is the load-bearing recent decision, d/101, and it is what keeps the install spectrum from turning into a store-like gate. Apps come in two tiers:

• Regular apps (the default, overwhelmingly). Ordinary web apps served plain http(s) at the device plane origin http://<app>.localhost:5454, framed and isolated by Prism’s Controlled Frame. No signing, no bundle format, no manifest requirement. The isolation you would otherwise pay for with per-app packaging is already delivered by the browser’s same-origin policy plus the Controlled Frame.
• Super web apps / super user agents (rare, opt-in). The Signed-Web-Bundle / Isolated-Web-App tier, reserved for shells that themselves need IWA-class powers — Controlled Frame hosting and agent-grade device surface. Prism is the canonical example.

The reasoning matters: requiring every app to be packaged as an Isolated Web App would rebuild exactly the store-like gate the litmus rejects. So an ordinary app never needs IWA packaging to be published, listed, or loaded. (This is current truth as of d/100/d/101/d/102/d/103; earlier serving decisions that assumed HTTPS-by-default and a different port are lineage, and the decisions ledger says so explicitly.)

Primer — Isolated Web Apps (IWA) & Controlled Frame: an Isolated Web App is a Chromium mechanism for a web app packaged and signed as a self-contained bundle, running in a stronger isolation context than an ordinary tab, and permitted to use powerful capabilities. A Controlled Frame (spec) is an embedding element available inside an IWA — a much stronger, fully partitioned cousin of the <iframe> — that lets a host app (Prism) frame and mediate another app. These are the primitives the L3 tier is built on; the rest of the site’s shell chapter goes deeper.

Peer topology

Multi-device is peer, not hub-and-spoke (d/062). Every device runs its own Xe Computer instance; there is no central server that owns your fleet. State syncs between instances as a first-class deliverable — the sync layer is not an add-on, it is part of the computer. This is called out as the costliest steer to reverse once sync formats ship, so format decisions are flagged loudly wherever they appear. A phone is a companion — a remote client and consent surface — not a sync peer (d/042).

Internet Archive & the DWeb context

The public stakes are raised by who is watching. The Internet Archive and the decentralized-web (DWeb) community are the first audience — Brewster Kahle has seen the work and the concept resonated (d/041); the backing is “warm.” The near-term community also includes the User & Agents circle. This is why the litmus is not negotiable marketing: the audience that would use this first is precisely the audience that will check whether you can inspect, fork, bring your own keys, move your memory, audit, and leave. The decisions ledger records how each of these commitments was turned into a concrete choice — read it next.