Repository navigation
id: design: capability model — requested vs discovered-used sets, registry listing, custom-compiled platforms #5958
Description
Part of the worlds design program: #5955. Statements S8–S16 of the 2026-11-04 brief.
Where we are (verified 2026-11-04)
An app's capabilities are already bounded upward by the platform used to compile it, and that bound can be securely listed per platform: the capability catalog and compile-time ceilings live in pkgs/id/crates/id-core/src/world_caps.rs.
Requirement (Drew, in substance)
- First, answer: do we currently have more than one platform? (S9 — an inventory fact this design starts from.)
- Direction: allow greater capabilities — this is a step towards reading and writing files from disk and using system resources. (S10)
- A world should be able to say what capabilities it requires — or, ideally, we can automatically derive and discover them. (S11)
- Capability vocabulary must at least express: standard, file read+write in the sandbox, arbitrary file read, arbitrary network out. (S12)
- The required capabilities are listed in the world's registry entry. (S13)
- If no existing platform fits, custom-compile the appropriate platform for that world. (S14)
- Handle the expansive-platform case: a user may give a world a platform with more capability than it uses. (S15)
- Therefore track two sets: requested (what the platform grants) and discovered-used (the exact functions really used). The registry says both: "it asks for all these, but it only uses this subset" — that helps users judge what they're connecting to. (S16)
Open questions
- Discovery mechanism: static analysis of the compiled world, platform-call instrumentation during a profiling run, or both? How are the two reconciled when they disagree?
- Is the used-set a property of the code (same for every run) or can it vary by path taken at runtime — and how does the registry present a path-dependent set honestly?
- Custom-platform compilation: who pays, how long does it take, is the result cached and shared across worlds with identical requirement sets (interacts with the compile-economics child of #5955)?
- How does the requested/used pair interact with writer-set authority (#5545) — is a capability grant an authority grant, or a separate axis?
Related
- Capability-provider parent: #5686; field survey #5931
- Provider registry (capabilities as manifest): #1061
- Core/app platform design: #2028
Done looks like
Design covering: platform inventory answer, capability vocabulary v1, declaration vs discovery, registry schema for requested/used sets, and the custom-platform compile path — each with the open questions above resolved or explicitly deferred with a reason.
Activity
developing-today commentedon Nov 5, 2026
CODE-1624
dezren39 commentedon Nov 5, 2026
Wave-2 tie-in (finding F10) + contradiction C2.
Settled architecture to cite: compile-time ceiling against the
world_caps.rscatalog; deterministic wasmtime fuel for Wasm guests; wall-clock deadlines + OS sandbox (no_new_privs, rlimits, seccomp allowlist with no open/sockets) for the admin-installed native tier, which is never peer-downloaded; presentation is data (record:workspace/scratch/worlds-capabilities-brief-2026-11-04/conversation-tie-ins.md, F10).C2 — WORKING INTERPRETATION — shown to Drew in the main chat 2026-11-04 ~23:06 and not objected to; recorded here as an interpretation, not a ruling. The brief's capability vocabulary for this design (standard, file read/write in the sandbox, arbitrary file read, arbitrary network out) is a deliberate posture change relative to the shipped catalog, which has no file or network capability at all and whose native-tier seccomp allowlist forbids open/sockets outright. Per the 2026-11-04 brief, this design proceeds on the new posture — the expansion is Drew's direction, recorded here so it isn't mistaken for silent catalog growth.
dezren39 commentedon Nov 5, 2026
Wave-2 follow-ups filed from the prior-art research (Lane B). Granular sub-scopes of this issue, each carrying the relevant research findings + citations:
Research source:
workspace/scratch/worlds-capabilities-brief-2026-11-04/prior-art-research.md. Full wave-2 mapping:workspace/scratch/worlds-capabilities-brief-2026-11-04/wave2-map.md.dezren39 commentedon Nov 5, 2026
Ruling — C2 capability posture (Drew, 2026-11-04 23:57 CST), with a correction to the working interpretation recorded earlier in this program.
Correction: the working interpretation said tonight's brief supersedes the shipped no-filesystem / no-network default. That is wrong. Per Drew's ruling, the default does not move:
dezren39 commentedon Nov 5, 2026
Triage — task 10327 (lane code-s)
Verdict: live design issue, correctly scoped, unblocked by Drew's C2 ruling (2026-11-04 23:57 CST). Stays OPEN; the design work itself is the follow-on, not a code fix.
Evidence checked fresh 2026-11-05:
pkgs/id/crates/id-core/src/world_caps.rsholds ONE static catalog (CATALOG_ENTRIES/ProviderRegistry). In the catalog's own vocabulary, "platform" =ProviderKind::PlatformModule, and there are exactly 6:Key,Screen,RocJson,RocGrid,RocCap,RocText— allDefaultCeiling::Included. In the execution-tier sense there are 2 tiers (per F10, recorded on this issue): the wasmtime Wasm-guest tier (deterministic fuel) and the admin-installed native tier (seccomp allowlist, never peer-downloaded). So: one catalog, six platform modules, two execution tiers — there is no per-world compiled platform selection today; that selection/custom-compile mechanism (S14) is precisely what this design must add.Ordering: #5958's core design (vocabulary v1, registry requested/used schema, custom-compile path) should land before or alongside its children #5998/#6000/#6017, which each presuppose the requested/used set definitions. No new follow-up task enqueued — children exist as issues and will be covered by queue intake; a duplicate design task here would violate one-issue-per-change.
Task 10327 completes as
triaged.