Umi is an OS; silos are apps

Umi is a secure operating system. Silos are the apps that run on it.

A silo is a full-stack mini-app — its own UI and its own backend (Email, Notes, …). Umi is the host: it holds the user’s data and mediates everything. A silo never reaches into that data directly. It requests capabilities (read the mail store, reach a network host, spend), the user grants them, and Umi enforces the grant at the boundary. The capability/consent system in umi-security is that permission model — the security boundary and the plugin boundary are the same thing.

That is what makes third-party silos possible and safe: someone outside the project can build a silo, and it can never touch anything the user did not grant. That is the goal.

The rule we hold now

A silo’s backend is capability-gated and out-of-process-able — never linked into Umi’s binary. Even first-party silos, compiled in-process today, only ever reach core through the capability-mediated API, as if they were already third-party. Hold that line and shipping real third-party silos later is extracting an existing boundary into a sandbox, not inventing one under pressure.

What we are not building yet: a plugin loader, a manifest spec, a WASM/sidecar runtime, or a marketplace. Those wait until there is a second silo author.

Scope right now

• Email is the first silo. It does not fully work yet; making it work across the capability-gated boundary is how we prove the model.
• Database and explorer are parked — back of mind until Email lands.