An open, web-first Linux OS.

Modern mobile platforms are extractive by design. App stores take 15–30% of every transaction. Proprietary SDKs create lock-in. Permission systems are theater. Inference features route personal data through corporate clouds. The device you own is a platform somebody else controls.

This project is a concrete engineering claim: a useful, daily-driveable operating system can be built entirely from open standards — and openness can be a structural property of the architecture, not a marketing promise.

Core Ethos

• Unexploitable by design. No party — including the OS authors — can extract rent from users or developers. The architecture makes it structurally impossible.
• Open by default. Every layer is open source. Every extension format is a web standard. No proprietary API, no SDK, no certification.
• Personal productivity first. Success is a daily driver the author actually uses — not market share, not a startup exit.
• Web platform as architecture. Chosen for composability, openness, and longevity — not as a shortcut.

The system is four layers interacting through well-defined interfaces. The key choice: the web renderer is not an app running on the OS — it is the OS surface. Analogous to ChromeOS, without the proprietary Chrome infrastructure.

The compositor does exactly three things: own the display, route input, bridge hardware to the web layer. Nothing else. Keeping it dumb and the web layer rich makes the system easier to port, test, and reason about.

Technology Choices

Rust for memory safety without a GC at the compositor level. Smithay (pure Rust Wayland) preferred; wlroots bindings as pragmatic fallback. IPC over Unix domain sockets with JSON or Cap'n Proto.

The shell is a collection of standard web components composing the visible interface of the OS. Every UI element is an auditable, replaceable HTML/CSS/JS component.

Shell API Surface

A small set of JavaScript APIs bridges to the compositor — the way browsers expose navigator.geolocation. Trusted shell components only, not arbitrary PWAs.

navigator.system.battery         // battery level + charging state
navigator.system.connectivity    // Wi-Fi, BT, network status
navigator.inference.complete(opts)      // inference routing (see §Inference)
navigator.capabilities.request() // trigger a permission prompt

Theming

CSS custom properties define the theming contract. Any component that respects it is automatically themeable. Themes install by URL, exactly like extensions — no proprietary theming SDK.

Permissions are declared in the manifest, not requested at runtime. The prompt is shown once, at install, in plain language. There are no pop-ups during use.

Design Principles

• Additive only. An extension can only do what it declared. It cannot escalate.
• Instant revocation from settings, at any time.
• Inference context never flows sideways. Screen → inference, never app A → app B. This blocks the surveillance model ad platforms depend on.
• The capability list is the audit trail. A reviewer can understand an extension's blast radius at a glance.

Inference is not an app. It is a system service — like networking or storage — that any component can request, subject to capability grants. What models run, where inference happens, and what data is shared stays entirely in the user's hands.

The navigator.inference API

Intentionally close to the W3C Prompt API proposal — ahead of the curve rather than inventing a proprietary interface.

const result = await navigator.inference.complete({
  prompt: "Summarize the selected text",
  context: ["screen", "clipboard"],  // requires capability grants
  model: "local/preferred"           // routing hint, not hard requirement
});

Model Registry

The system ships a curated model manifest (JSON) listing available models, sizes, capabilities, and sources. The manifest is just a URL. Users can add third-party registries like apt sources. No gatekeeping. Onboarding asks "What do you want Inference to help with?" and recommends based on answers and storage. LAN endpoints (e.g. Ollama) auto-discover via mDNS.

Hardware is selected on driver openness first, specs second. The Steam Deck running mainline Linux is the initial target — chosen for driver quality, not TDP. Qualcomm Adreno needs firmware blobs; Mali via Panfrost lags new generations; modems are almost universally proprietary. The Deck sidesteps most of this.

Long-Term: RK3588 ARM Port

Once stable on the Deck, the compositor ports to ARM targeting the RK3588. Its dedicated NPU means on-device Inference has a fast path that doesn't compete with the GPU. The web shell layer ports without significant rework — it's already architecture-independent.

What Makes This Distinct

No existing project combines all of the following:

• Thin Rust/native compositor — not Gecko, not GTK
• Web renderer as the primary shell surface, not an embedded runtime
• Standard web components as the extension and widget model
• Capability-based, declarative, human-readable permissions
• PWAs installable by URL, no central gatekeeper
• Inference as a system service with local-first, tiered inference routing

Success is a daily driver the author uses. Milestones are ordered to demonstrate the thesis as early as possible — each one is a credible demo, not just a checkpoint.

1. M0 — Hello World. Rust compositor running. Web renderer shows a static HTML page fullscreen on the Deck. Days.
2. M1 — Web Shell. Status bar, launcher grid, gesture navigation mounted as web components. Weeks.
3. M2 — First PWA. A PWA launches, runs, closes, returns to home. Touch works. Weeks.
4. M3 — First Extension. A web component installs via URL and appears in the shell. The thesis is proven.
5. M4 — Prototype Alpha. Full home screen, Wi-Fi settings, lock screen. Usable day-to-day.
6. M5 — Inference Integration. Local model selected at setup. navigator.inference live. Writing assistant as reference extension.
7. M6 — Daily Driver. Stable as the author's primary device. Extension ecosystem seeded. Developer docs.