Remembering Firefox OS (And What It Got Right)

WEFT OS In One Sentence

A Simple Mental Model: Three “Rooms” Talking

What Actually Happens When You Launch An App

1. You click the icon

2. The click becomes a message

3. The daemon sets up a safe environment

4. The app starts and announces “I’m ready”

Why This Is Different From “Just Use The Browser”

Reliability: What Happens When Things Go Wrong

Example 1: App never says “READY”

Example 2: UI shell can’t create a window

Example 3: Background IPC channel dies mid‑session

Security and Privacy: Capabilities, Not “All Or Nothing”

Why Architects Might Care

Why Non‑Technical People Might Care

Closing Thoughts

marcoallegretti / WEFT_OS

WEFT OS is an experimental operating system built around WebAssembly, Servo, and Wayland, designed to run secure, GPU-accelerated web and Wasm applications in a modular package-based system.

WEFT OS

What is implemented When people hear “new operating system,” they usually think of big consumer products: Windows, macOS, Android, iOS.

When developers hear “new OS,” they often think of hobby projects that boot, show a prompt, and stop there. WEFT OS is neither of those. It is a serious attempt to answer a simple question: If we took the best ideas from Firefox OS — the idea that apps are just web content — and rebuilt them with modern isolation, security, and reliability in mind, what would that operating system look like? This article walks through that answer in plain language.It is written for a general audience, but it is precise enough that a senior systems architect should recognize the design patterns and trade‑offs. Firefox OS tried something bold:instead of installing “native” apps, you would run applications built with web technologies — HTML, CSS, JavaScript — directly on the phone. It got a few important things right: The web as the app platform.You don’t compile separate apps for every device. You build with the web stack developers already know. Permissioned capabilities.Apps didn’t just get full device access. They had to declare which things they used (camera, contacts, etc.). Simple deployment.Apps were essentially packaged websites, not massive native binaries. What went wrong is more complex: hardware realities, market timing, and some architectural limits.But the core idea — “the web as a first‑class app platform” — never stopped being interesting. WEFT OS picks that idea back up, but with a much stricter focus on: WEFT OS is an operating system that treats the web as the primary UI layer, runs each app in its own isolated sandbox, and connects everything through explicit, inspectable IPC (inter‑process communication) contracts. That’s a mouthful, so let’s unpack it in human terms. Imagine WEFT OS as a small house with three main rooms: The Display Room – “the compositor”This is the part that actually talks to your monitor and input devices (keyboard, mouse, touch).It knows how to draw windows, move them around, and react when you click or type. The System UI Room – “system shell”This is where the system interface lives:task switcher, status bar, notifications, “home screen”, system dialogs.In WEFT OS, this entire room is a single web page running in an embedded browser engine. The App Rooms – “app runtimes”Each app gets its own small, locked‑down room.Inside it runs app logic and UI, also driven by web technologies and WebAssembly.Every app room is separate from every other app room. The key is how these rooms talk.In WEFT OS, they don’t reach into each other’s memory.They send messages over well‑defined channels, like people passing written notes under the door. That sounds slow and over‑engineered.But it buys you three things that are very hard to retrofit into a traditional desktop OS: Let’s walk through a concrete example: opening a “Notes” app on WEFT OS. Instead of launching some random binary directly, the system UI sends a structured message to a background service: “Please start app com.example.notes for session 12345.” This background service is the app daemon.Its job is to manage app lifecycles: start, stop, track state. Before any app code runs, WEFT OS: Works out which files and folders the app is allowed to see.For example: a per‑app data directory, maybe a shared “Documents” folder, nothing else. Optionally launches a file portal process.This is a small helper that sits between the app and your real filesystem.The app asks the portal to read or write files; the portal enforces the rules. Prepares IPC sockets (communication channels) so that: Only after all that is in place does the daemon start the app’s runtime process. Inside the app room, the runtime boots: When initialization is complete, the app runtime simply prints one line: The daemon watches for that.If it doesn’t see READY within a fixed time window, the daemon: If it does see READY, the daemon: The result: when the Notes window appears, it has already proved that: There is no half‑started zombie process hanging around. You could ask: why not just run everything in browser tabs? Three big differences: Ownership of the screenIn WEFT OS, the compositor is not the browser; it is the OS component that controls displays and input directly.The system UI and apps are guests in that space, not owners of it. Hard isolation by processEach app runs in its own dedicated process with a very narrow view of the filesystem and OS services.It doesn’t share memory with other apps.If the app crashes, the compositor and system shell stay alive. IPC as a contract, not an afterthoughtInstead of arbitrary internal calls, components communicate via structured messages with clearly defined types.For a senior architect, this looks much more like micro‑services than a monolithic desktop shell. You still get the productivity of the web stack, but on top of an OS that behaves more like a collection of small, cooperating services than a single giant program. Because everything is separated, WEFT OS can make failure a first‑class case, not an exception. A few concrete examples: The app starts, but never prints READY — maybe it’s stuck in initialization, or crashed silently. To the user, this looks like:“Notes failed to start. Try again or check logs.” To an architect, this is: The UI shell is the embedded browser used to render the system UI or an app window.If window creation fails (for example, graphics issues), WEFT OS: The compositor itself stays alive; it doesn’t crash just because an app window failed to open. Apps talk to the daemon and other components over local sockets.If that socket breaks: These are small details in code, but collectively they define a failure‑aware OS, where the normal path and the error path are equally designed. Traditional desktop apps often see your entire home directory by default.On phones, apps ask for broad permissions: “Photos”, “Files”, etc. WEFT OS takes a narrower approach: To a non‑technical user, this means: “An app only sees the folders it really needs, not your whole system.” To an architect, it means: From a systems‑design point of view, WEFT OS has a few interesting properties: Clear component boundaries Everything talks via messagesIPC is not a side detail; it is the backbone of the system.That makes it possible to: Failure is explicitTimeouts, missing binaries, socket errors, window creation failures — all mapped to: Web UI without “Electron bloat”Instead of every app bundling its own browser, the OS provides a shared, deeply integrated browser engine as a core service.Apps are guests; the OS remains in charge. You can think of WEFT OS as a small, service‑oriented system for running web apps, rather than “yet another Linux desktop.” If you are not a systems engineer, most of the above might sound abstract.Here is what it means in everyday terms: Apps feel like websites, but behave like proper apps.They can send notifications, access your files (within limits), and integrate into the system UI. Crashes are less scary.If your Calendar app dies, it should not bring down your whole desktop. Permissions are more understandable.Instead of giving apps the keys to everything, the OS can say:“This app can only see this folder and talk to this service.” It is easier to inspect and debug problems.Because everything is message‑based, operators and developers can see where something went wrong:“The app never sent READY”, “The IPC channel broke”, “The portal denied this path”. WEFT OS is not trying to compete with the big general‑purpose desktops on features.Instead, it explores a focused idea: If Firefox OS was an early experiment in “the web as an OS,”WEFT OS is a modern, more careful experiment in “the web, but with strong isolation and explicit contracts.” For non‑technical readers, the takeaway is: This operating system is built so that apps behave more like well‑behaved website tabs, and less like all‑powerful desktop programs. For architects, the takeaway is: This is a message‑driven, componentized OS with clear boundaries, capability‑based access, and designed‑in failure handling — using the web stack as its primary UI layer. If you are curious, the next step is simply to explore:read the architecture docs, look at how sessions move from “Requested” to “Running” to “Stopped,” and see how much complexity disappears once you treat the OS itself as a set of contracts between small, cooperating processes. WEFT OS is a Wayland compositor and application runtime where every app is a WebAssembly component rendered in an isolated Servo WebView. No capability is granted by default; all resource access is declared in a per-app manifest and enforced at runtime. Compositor — weft-compositor is a Smithay-based Wayland compositor with DRM/KMS and winit backends. It implements the zweft-shell-unstable-v1 protocol extension, which typed shell slots (panel, application) register against. System shell — weft-servo-shell embeds Servo (feature-gated, --features servo-embed) and renders system-ui.html as a Wayland panel. Without servo-embed, the binary builds as a no-op stub. Navigation gestures from the compositor are forwarded to weft-appd over WebSocket. App shell — weft-app-shell is a per-process Servo host for application WebViews. It resolves weft-app://<id>/ui/index.html, injects a weftIpc WebSocket bridge into the page, and registers with the compositor as an application surface. Also feature-gated behind servo-embed. If you find this idea interesting, leave a comment.If you think it's crazy: leave a comment and debunk my idea. If you'd like to give me a little support, leave a Star on the GitHub repository. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - The web as the app platform.You don’t compile separate apps for every device. You build with the web stack developers already know.- Permissioned capabilities.Apps didn’t just get full device access. They had to declare which things they used (camera, contacts, etc.).- Simple deployment.Apps were essentially packaged websites, not massive native binaries. - Isolation: every app is strongly contained.- Contracts: components talk over clearly defined channels.- Reliability: one broken app should not bring down your session. - The Display Room – “the compositor”This is the part that actually talks to your monitor and input devices (keyboard, mouse, touch).It knows how to draw windows, move them around, and react when you click or type.- The System UI Room – “system shell”This is where the system interface lives:task switcher, status bar, notifications, “home screen”, system dialogs.In WEFT OS, this entire room is a single web page running in an embedded browser engine.- The App Rooms – “app runtimes”Each app gets its own small, locked‑down room.Inside it runs app logic and UI, also driven by web technologies and WebAssembly.Every app room is separate from every other app room. - Crashes are contained.- Permissions are explicit.- Behavior is inspectable and testable end‑to‑end. - You see a system UI page — think of it like a “desktop” or “home screen.”- That UI is just HTML + CSS + JavaScript rendered by Servo (a modern browser engine).- You click the “Notes” icon. - Works out which files and folders the app is allowed to see.For example: a per‑app data directory, maybe a shared “Documents” folder, nothing else.- Optionally launches a file portal process.This is a small helper that sits between the app and your real filesystem.The app asks the portal to read or write files; the portal enforces the rules.- Prepares IPC sockets (communication channels) so that: The app can send and receive messages (for example, to the system UI).The system can observe and control its lifecycle.- The app can send and receive messages (for example, to the system UI).- The system can observe and control its lifecycle. - The app can send and receive messages (for example, to the system UI).- The system can observe and control its lifecycle. - It loads the app’s code (WebAssembly / web code).- It sets up the local environment (permissions, pre‑opened directories, IPC).- Crucially, it does not get full system access; it only sees what was explicitly granted. - Kills the app process.- Cleans up its file portal.- Marks the session as “Stopped”.- Notifies the rest of the system that this launch failed cleanly. - Marks the session “Running”.- Sends a message back to the system UI: “Notes app session 12345 is ready.”- Optionally launches a per‑app UI shell (another browser instance) to render the app’s front‑end. - Its code loaded correctly.- Its IPC channels work.- Its basic environment is valid. - Ownership of the screenIn WEFT OS, the compositor is not the browser; it is the OS component that controls displays and input directly.The system UI and apps are guests in that space, not owners of it.- Hard isolation by processEach app runs in its own dedicated process with a very narrow view of the filesystem and OS services.It doesn’t share memory with other apps.If the app crashes, the compositor and system shell stay alive.- IPC as a contract, not an afterthoughtInstead of arbitrary internal calls, components communicate via structured messages with clearly defined types.For a senior architect, this looks much more like micro‑services than a monolithic desktop shell. - Waits up to a fixed timeout (e.g. 30 seconds).- If READY never appears: Kills the app process.Shuts down the app’s file portal.Marks the session as Stopped.Broadcasts that new state to anyone interested (e.g. the system UI).- Kills the app process.- Shuts down the app’s file portal.- Marks the session as Stopped.- Broadcasts that new state to anyone interested (e.g. the system UI). - Kills the app process.- Shuts down the app’s file portal.- Marks the session as Stopped.- Broadcasts that new state to anyone interested (e.g. the system UI). - A clear state machine: Starting → Running or Stopped.- No “half alive” processes.- A single place (the app daemon) responsible for enforcing this policy. - Logs a clear error.- Exits the shell process cleanly.- Tells the event loop to stop instead of panicking the whole program. - The daemon notices.- It cleans up the session and updates state.- The system UI can show “Disconnected” instead of hanging indefinitely. - Each app declares capabilities such as “needs persistent app data” or “needs access to Documents”.- The app daemon turns those into pre‑opened directories:“You can see /data and /xdg/documents, nothing else.”- A separate file portal process enforces this at runtime: It receives file read/write requests from the app.It checks them against the allow‑list.It can log or deny anything outside the allowed paths.- It receives file read/write requests from the app.- It checks them against the allow‑list.- It can log or deny anything outside the allowed paths. - It receives file read/write requests from the app.- It checks them against the allow‑list.- It can log or deny anything outside the allowed paths. - No direct filesystem syscalls from app code to arbitrary paths.- A single choke point for policy (the portal).- Easier reasoning about what data an app can touch. - Clear component boundaries Compositor: owns displays and input.Shells (system + per‑app): own UI and user interactions.App daemon: owns lifecycle and session state.Runtime: owns execution of app code.File portal: owns filesystem policy.- Compositor: owns displays and input.- Shells (system + per‑app): own UI and user interactions.- App daemon: owns lifecycle and session state.- Runtime: owns execution of app code.- File portal: owns filesystem policy.- Everything talks via messagesIPC is not a side detail; it is the backbone of the system.That makes it possible to: Trace flows end‑to‑end.Test components in isolation with fake messages.Swap implementations without changing contracts.- Trace flows end‑to‑end.- Test components in isolation with fake messages.- Swap implementations without changing contracts.- Failure is explicitTimeouts, missing binaries, socket errors, window creation failures — all mapped to: Well‑defined log messages.State changes (Starting → Stopped).Predictable cleanup.- Well‑defined log messages.- State changes (Starting → Stopped).- Predictable cleanup.- Web UI without “Electron bloat”Instead of every app bundling its own browser, the OS provides a shared, deeply integrated browser engine as a core service.Apps are guests; the OS remains in charge. - Compositor: owns displays and input.- Shells (system + per‑app): own UI and user interactions.- App daemon: owns lifecycle and session state.- Runtime: owns execution of app code.- File portal: owns filesystem policy. - Trace flows end‑to‑end.- Test components in isolation with fake messages.- Swap implementations without changing contracts. - Well‑defined log messages.- State changes (Starting → Stopped).- Predictable cleanup. - Apps feel like websites, but behave like proper apps.They can send notifications, access your files (within limits), and integrate into the system UI.- Crashes are less scary.If your Calendar app dies, it should not bring down your whole desktop.- Permissions are more understandable.Instead of giving apps the keys to everything, the OS can say:“This app can only see this folder and talk to this service.”- It is easier to inspect and debug problems.Because everything is message‑based, operators and developers can see where something went wrong:“The app never sent READY”, “The IPC channel broke”, “The portal denied this path”. - Web technologies as the primary UI.- Small, isolated runtimes for each app.- A compositor and daemon that treat contracts, capabilities, and failures as first‑class citizens.