I’ve been working through an idea I’m calling CanOS and want to get some pushback before I go further with it.
The basic question is whether a device needs to host its own OS at all, or whether it could just render and execute one that actually lives in a canister.
I keep landing on three different ways this could go, and they’re genuinely different bets, not just variations on one idea.
Option 1: CanOS as a runtime
CanOS sits on top of existing platforms. You’d have a Wasm-based runtime and SDK running on Windows or macOS today, using ICP and Chain Fusion for backend services. It’s the safest option and the one that ships fastest, but it’s basically a cross-platform app runtime with ICP wired in, nothing more radical than that.
Option 2: CanOS as an ICP-powered OS
This is more extreme: the canister holds the entire OS state — apps, files, identity, settings, all of it — and the device runs a thin binder layer that just handles hardware I/O and rendering. The device stops being the source of truth. You’d pick up any CanOS device, log in, and your whole environment is there because it never actually lived on the hardware.
This one’s appealing but it’s also the hardest to pull off, since a canister obviously can’t touch a modem or a GPU directly, so you still need some local trusted execution layer to bridge that gap — and that’s not a solved problem.
Option 3: Canisters as apps, with a native-feeling frontend
This treats canisters as individual apps, but wraps them in a native-feeling frontend language instead of the usual clunky blockchain UI. The developer writes UI and application logic, the canister handles state and backend, and the framework compiles it down to something that feels like a normal native app.
This is probably the most practical starting point, since it avoids the “make a canister run an entire phone OS” problem and just asks whether a canister-backed app can feel indistinguishable from a locally-built one.
The 0.1 beta plan
Start with Option 1: SDK, runtime, Wasm, running on Windows and macOS with ICP and Chain Fusion underneath. Design the runtime/API contract cleanly enough that the same app model could move to Android or eventually purpose-built hardware without developers rewriting anything.
What about watches?
I think it’s realistic further down the line, though it flips which architecture makes sense. A watch has almost nothing in the way of local compute or storage, so Option 2 (canister-as-OS) actually fits better there than on a phone, since the device barely has to do anything beyond render and relay input. Latency to the canister becomes the thing that decides whether it’s usable at all. Option 3 doesn’t map as well to a watch since “app” is a thinner concept there to begin with.
Questions I’d like feedback on
- Has anyone tried building a local trusted execution layer for something like this, or is that closer to a research problem than an engineering one?
- Is there prior art on IC for a declarative UI layer that compiles down to canister calls?
- Does anyone have experience with low-power devices talking to canisters where latency was tight enough to matter?
Open to going deeper on any of this.
@infu would appreciate your feedback