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.
Remembering Firefox OS (And What It Got Right)
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:
- Isolation: every app is strongly contained.
- Contracts: components talk over clearly defined channels.
- Reliability: one broken app should not bring down your session.
WEFT OS In One Sentence
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.
A Simple Mental Model: Three “Rooms” Talking
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:
- Crashes are contained.
- Permissions are explicit.
- Behavior is inspectable and testable end‑to‑end.
What Actually Happens When You Launch An App
Let’s walk through a concrete example: opening a “Notes” app on WEFT OS.
1. You click the icon
- 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.
2. The click becomes a message
Instead of launching some random binary directly, the system UI sends a structured message to a background service:
“Please start app
com.example.notesfor session12345.”
This background service is the app daemon.
Its job is to manage app lifecycles: start, stop, track state.
3. The daemon sets up a safe environment
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:
- The app can send and receive messages (for example, to the system UI).
- The system can observe and control its lifecycle.
Only after all that is in place does the daemon start the app’s runtime process.
4. The app starts and announces “I’m ready”
Inside the app room, the runtime boots:
- 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.
When initialization is complete, the app runtime simply prints one line:
READY
The daemon watches for that.
If it doesn’t see READY within a fixed time window, the daemon:
- 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.
If it does see READY, the daemon:
- 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.
The result: when the Notes window appears, it has already proved that:
- Its code loaded correctly.
- Its IPC channels work.
- Its basic environment is valid.
There is no half‑started zombie process hanging around.
Why This Is Different From “Just Use The Browser”
You could ask: why not just run everything in browser tabs?
Three big differences:
Ownership of the screen
In 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 process
Each 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 afterthought
Instead 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.
Reliability: What Happens When Things Go Wrong
Because everything is separated, WEFT OS can make failure a first‑class case, not an exception.
A few concrete examples:
Example 1: App never says “READY”
The app starts, but never prints READY — maybe it’s stuck in initialization, or crashed silently.
What WEFT OS does:
- Waits up to a fixed timeout (e.g. 30 seconds).
- If
READYnever 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).
To the user, this looks like:
“Notes failed to start. Try again or check logs.”
To an architect, this is:
- A clear state machine: Starting → Running or Stopped.
- No “half alive” processes.
- A single place (the app daemon) responsible for enforcing this policy.
Example 2: UI shell can’t create a window
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:
- Logs a clear error.
- Exits the shell process cleanly.
- Tells the event loop to stop instead of panicking the whole program.
The compositor itself stays alive; it doesn’t crash just because an app window failed to open.
Example 3: Background IPC channel dies mid‑session
Apps talk to the daemon and other components over local sockets.
If that socket breaks:
- The daemon notices.
- It cleans up the session and updates state.
- The system UI can show “Disconnected” instead of hanging indefinitely.
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.
Security and Privacy: Capabilities, Not “All Or Nothing”
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:
- 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
/dataand/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.
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:
- 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.
Why Architects Might Care
From a systems‑design point of view, WEFT OS has a few interesting properties:
-
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.
-
Everything talks via messages
IPC 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.
-
Failure is explicit
Timeouts, missing binaries, socket errors, window creation failures — all mapped to:- 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.
You can think of WEFT OS as a small, service‑oriented system for running web apps, rather than “yet another Linux desktop.”
Why Non‑Technical People Might Care
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”.
Closing Thoughts
WEFT OS is not trying to compete with the big general‑purpose desktops on features.
Instead, it explores a focused idea:
- 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.
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.
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
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.
What is implemented
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.
App…
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.
Top comments (0)