World Computer after 0.8.0: capsules that run anywhere, WebSpaces as data stores, tradable capsules #285

Vision review (7 Oct) against the World Computer paper and PRINCIPLES.md. The first release (0.8.0, #93) is a host-run web app platform with honest docs (#199); these are the gaps to the vision, kept here so 0.8.0 stays on its five goals.

Capsules that run anywhere (DigitCapsules). Today UI apps are web projections hosted by the Runtime and providers are native host processes (docs/CAPSULE_AUTHORING.md:13-16, 38-40; templates/capsules/provider-contract teaches the native model). The vision: each app runs as WASM in its own virtual machine with no direct network.

• Resident WASM components with UI channels: Bus v2: resident WASM components with UI channels #181
• VM capsules beyond the Browser engine: VM capsules beyond the Browser engine #182
• Provider template teaches the confined model once Confine every native provider and stop handing it the device key #166 lands (0.8.0 gate)

WebSpaces as active, shared data stores. Today WebSpaces are resolver mounts and forks; sync and availability are left to providers (docs/NAMESPACES.md:58-64, GLOSSARY.md:342-356, P8).

• Write the target design: a WebSpace as a shared, synced data space with owner-granted access, no ambient authority

Tradable capsules as digital goods. Content trading is documented (docs/PROTECTED_CONTENT.md, #91); apps as limited-edition, tradable capsules are not (deferred in docs/audits/2026-09-23-open-backlog-snapshot.md:511).

• Write the design: scarcity and transfer of a capsule's rights, built on CID identity and After 0.8.0: Protected content #91's rights contracts

Related: #281 anyone can host signed capsules; #209 keys the host cannot read.

North star review (10 Oct)

The World Computer vision was checked against this repository, then attacked by a devil's-advocate review and a second model family. Terms that differ between the vision and the code are listed in docs/GLOSSARY.md.

Decisions

• No interface freeze before a prototype. Capabilities become host-side handles bound to instance and session (Runtime places scoped, short-lived app capabilities into each frame, with real stop #177). The Bus evolves under Bus v2: resident WASM components with UI channels #181 with typed, versioned operations. A fixed four-call surface was rejected: it moves the real contract into free-text operation names.
• Licence and right checks happen in Runtime, at admission and at protected effects, with renewal or revocation for running instances. Code inside a capsule never enforces them.
• Honest promises: tradable, ledger-limited rights; copy protection only with custody plus hardware attestation; no "Sybil-proof" or absolute "no man-in-the-middle" claims.
• Portability lives at the capsule layer: WASM capsules and web apps run unchanged on every CPU. Heavy native engines (Chromium, llama.cpp, Kubo) ship one native payload per platform under one capsule identity, built from one pinned recipe, like the Runtime binary. A browser engine compiled to WASM cannot use its native JavaScript compiler, so it would not reach native speed.
• Nothing here starts before 0.8.0 except docs and the Design: Home GUI as a sandboxed capsule with a Runtime-owned host #172 threat-model design.

Contradictions to resolve

1. Licence checks inside the capsule vs Runtime enforcement: code on hardware the owner controls cannot protect itself.
2. Trusted hardware "rooted in" the chain vs hardware as the root of trust: a chain can only be the registry of trusted builds and signers.
3. "Runs on Linux, macOS and Windows" vs "Linux in firmware": two host profiles, app now and appliance later.
4. "Conceal the Internet" vs DNS-owned names: DNS names bring back DNS trust; names should resolve to a DID once and be pinned.
5. "The system does not launch apps directly" vs today: Runtime hosts Home and apps as web pages, and providers are native processes.
6. Policy in the shell vs Runtime policy vs DAO-approved parties: Runtime keeps a minimum policy; shells, agents and DAO lists may only tighten it or propose.
7. Tradable goods vs revocation: safety revocation (malware) and licence ownership (ledger) must stay separate powers.
8. Public on-chain holders vs private data: holding should use a pseudonymous key per capsule.
9. "Frozen forever" vs a still-changing Component Model.
10. "Very hard to attack" vs reality: hidden addresses stop direct targeting, but Sybil resistance needs an identity cost, and relays and gateways remain targets.
11. "RTOS" vs no real-time guarantee in a WASM capsule.
12. "Carrier" used for the kernel vs Carrier as transport only (P4).
13. Separate address spaces per vendor vs today: WASM components share the Runtime process and its keys.

Gaps in today's code

• No event or wait interface; components are run-once (Bus v2: resident WASM components with UI channels #181)
• Provider names come from a hard-coded list, not signed bindings
• Signatures cover the manifest and entrypoint, not every file (update: every capsule signed independently; updates replace only changed capsules #274)
• Home can obtain every app's capability (Home: split into a Runtime-owned host and a sandboxed Home GUI capsule #176, Runtime places scoped, short-lived app capabilities into each frame, with real stop #177)
• Providers run with the user's rights (Confine every native provider and stop handing it the device key #166)
• No trusted approval region a capsule cannot draw over (Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178)

Order after 0.8.0

• Prototype handles, typed operations and a small guest SDK; freeze only after it (Bus v2: resident WASM components with UI channels #181)
• Key-free, confined worker processes for executable capsules, before any third-party executable capsule is admitted (Design: Home GUI as a sandboxed capsule with a Runtime-owned host #172)
• Whole-closure signing and nested hash checks at admission (update: every capsule signed independently; updates replace only changed capsules #274), then pinned provider identity before any on-demand provider launch
• Trusted approval surface before a capsule can request consequential authority (Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178)
• Rights at admission plus renewal and revocation for running instances; pseudonymous holder keys (After 0.8.0: Protected content #91)
• Binary transparency: release hashes and signer DIDs anchored on ELA (after Publisher key rotation without reinstalling: a root key delegates release signing keys #213)

Open questions

1. Is Carrier transport only, with the Runtime as the kernel and the RTOS-Runtime as the SDK linked into each capsule?
2. Does "RTOS" mean embedded-style rather than real-time?
3. Does "limited edition" mean ledger scarcity unless hardware attestation is present?
4. Icon-NFT: one per edition or per licence copy, behaviour on update, pseudonymous holders?
5. Who in the DAO approves names and contracts, and when?
6. Which trusted-hardware types count, and is the appliance image a 1.0 goal?
7. Runtime minimum policy, with shells and agents only proposing or tightening?
8. COMO/Naori: WASM-native, or C++ compiled to WASM?