Skip to content

Apps' own WebAssembly functions: the wasm capability (contract 1.7.0), wasm.<function> tools and fns/*.wasm in the store gate - #140

Merged
ymote merged 3 commits into
mainfrom
feat/wasm-capability-mvp
Oct 8, 2026
Merged

ymote merged 3 commits into
mainfrom
feat/wasm-capability-mvp

Conversation

@ymote

@ymote ymote commented Oct 8, 2026 •

Copy link
Copy Markdown
Collaborator

What this changes

An app may ship its own functions as WebAssembly modules in fns/*.wasm, and the host runs them for that app only. This PR is App Hub's side: the contract, the agent-tool rule and the store gate. OctoSense's runtime and wasm service are in OctoSense-org/OctoSense#364, which pins this branch.

  • app-contract 1.7.0: KNOWN_CAPABILITIES gains wasm. (1.6.0, from Expose versioned host APIs and execute admitted app tools #138, is already on crates.io.) A function gets its input and returns its output; it reaches no file, network, clock or other app. The grant implies no other capability. The store shows "Run its own sandboxed functions on this device".
  • app-policy: a tool may name host_method: "wasm.<function>" to run the app's own function. It needs the wasm capability. Unlike the reviewed shared host methods it has no risk floor and no private_data requirement, because the function sees only the arguments it is given. app-policy now asks for contract 1.7.
  • store gate: .wasm becomes the one executable a bundle may carry, under these rules:
    • Location and name: only at fns/<name>.wasm, the name [a-z0-9_-] and at most 64 characters.
    • Contents: only a WebAssembly core module (magic and version 1).
    • Count: at most 8 per bundle.
    • Capability: only when the manifest declares wasm.
    • Warning: declaring wasm without any module.
    • Left to the host: a module's imports and exports, checked when it loads.
  • Docs, English and Chinese:
    • PUBLISHING gains the functions check, the wasm capability row, and wasm.<function> in the host_method rules.
    • SUBMITTING lists wasm among the capabilities released stores refuse.
    • The READMEs say no release serves wasm yet.

Release

The crate goes to 1.7.0 with a CHANGELOG entry. Per the contract's release rules, it needs review from App Hub and one app owner (Rinx) before publish-app-contract runs. 1.7.0 is not published; until it is, a consumer patches crates.io's copy with this repository's revision, as the contract README describes.

How it was tested

  • On main after Expose versioned host APIs and execute admitted app tools #138, cargo test --locked -p octosense-app-contract -p octosense-app-policy -p octosense-app-hub: 228 passed, 0 failed. New tests:
    • three gate tests for function modules;
    • one contract growth test;
    • one test for wasm.<function> as a host method.
  • The contract crate copied out of the workspace, as app-contract.yml runs it:
    • cargo test --all-targets: 37 passed;
    • cargo test --doc: 2 passed;
    • cargo clippy --all-targets --no-deps -- -D warnings: clean.
  • End to end, through OctoSense's wasm-lab build (Apps' own Rust functions in WebAssembly, behind the wasm-lab feature (ADR 0011) OctoSense#364):
    • on macOS, the system app os.wasmlab declared wasm and its agent's tools used host_method: "wasm.<function>", admitted by this policy;
    • the same app ran on an Android phone.
  • Not tested: a store-installed app with fns/*.wasm running on a device. Today's OctoSense builds don't install from a catalog with a 1.6.0 app.

The design and measurements are in ADR 0011 (proposed), in OctoSense-org/OctoSense#364.

🤖 Generated with Claude Code

@ymote
ymote force-pushed the feat/wasm-capability-mvp branch from f5434fa to 21d7c8b Compare October 8, 2026 00:35
@ymote ymote changed the title Apps' own WebAssembly functions: the wasm capability (contract 1.6.0), wasm.<function> tools and fns/*.wasm in the store gate Apps' own WebAssembly functions: the wasm capability (contract 1.7.0), wasm.<function> tools and fns/*.wasm in the store gate Oct 8, 2026
ymote and others added 3 commits October 7, 2026 17:48
KNOWN_CAPABILITIES gains `wasm`: the app's own functions, WebAssembly
modules in its bundle's fns/, run by the host's `wasm` service in a sandbox
with a deadline and a memory cap. A function gets its input and returns its
output; it reaches no file, network, clock or other app, and the grant
implies no other capability. The store shows "Run its own sandboxed
functions on this device"; the listing's line says what they cannot reach.

A growth test pins it as its own exact grant. 1.7.0 is not on crates.io;
publishing follows review (publish-app-contract).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A tool may route to the app's own WebAssembly function with
host_method "wasm.<function>". The host runs the bundle's module in a
sandbox where the function reaches nothing but its input, so it is outside
the reviewed shared-service list and has no risk or private_data floor;
the manifest must still declare `wasm`. app-policy now asks for contract
1.7, which knows the capability.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A WebAssembly module becomes the one executable a store bundle may carry:
at fns/<name>.wasm ([a-z0-9_-], at most 64 characters), a core module
(magic and version 1), at most 8 per bundle, and only when the manifest
declares `wasm`. A module elsewhere, misnamed or not wasm is refused as
contents-invalid; one without the capability, or a ninth, as `functions`;
the capability without modules is a warning. The host checks a module's
imports and exports when it loads it.

PUBLISHING and SUBMITTING (English and Chinese) gain the `functions` check,
the `wasm` row, and `wasm.<function>` in the host_method rules, and say
that no release serves it yet; the READMEs say the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ymote
ymote force-pushed the feat/wasm-capability-mvp branch from 21d7c8b to b7fa3ab Compare October 8, 2026 00:48
@ymote

ymote commented Oct 8, 2026

Copy link
Copy Markdown
Collaborator Author

Local CI on b7fa3ab (this branch rebased on main e812331), macOS arm64, the steps of native-tools.yml (standalone, whose macOS runner is still queued) and app-contract.yml, with the sibling sources prepared and verified by Octoscript-Makepad 33dea2f1's runtime.py (makepad 32d6415f, octoscript 2e37d9e6):

PASS  build card-host + app-hub (release)  (79s)
PASS  contract, policy and hub tests (release)  (26s)
PASS  card-host CLI tests  (2s)
PASS  appstore lib (no default features)  (33s)
PASS  app-hub-app lib (no default features)  (47s)
PASS  card-host bin tests  (3s)
PASS  native bundled-font path  (3s)
PASS  contract: tests (standalone)  (14s)
PASS  contract: doc tests (standalone)  (1s)
PASS  contract: clippy (standalone)  (3s)

semver passed on GitHub for this contract source; the rebase changed nothing under crates/app-contract. Merging per the agreed order: this PR, then publishing app-contract 1.7.0, then repinning OctoSense#364.

🤖 Generated with Claude Code

@ymote
ymote merged commit 2e57689 into main Oct 8, 2026
3 checks passed
tyreseluo pushed a commit to tyreseluo/OctoSense-App-Hub that referenced this pull request Oct 12, 2026
publish-app-contract published octosense-app-contract 1.7.0 (the `wasm`
capability, OctoSense-org#140) on 2026-10-07. The CHANGELOG, the contract README's
"Versions on crates.io" and AGENTS.md now say so, and that
`cargo update -p octosense-app-contract` moves a consumer to 1.7.0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant