Capabilities

Type

interface RuntimeCapabilityRegistry {
  has(name: string): boolean;
  list(): string[];
  grant(name: string): void;
  revoke(name: string): void;
}

What's shipped in v0.1

Default grants:

The registry is a string set. Today the runtime only checks has internally for ui.render (whether to mount the Preact widget). Other capabilities are declared so hosts can introspect what the runtime believes is available.

Inspecting from your host

runtime.capabilities.list();
// ["storage.local", "transport.browser-fallback", "transport.direct", "transport.dartc", "ui.render"]

runtime.capabilities.has("transport.browser-fallback");
// true (if navigator.gpu was detected)

What's planned

A richer request<T>(name, input?) flow that:

1. Lets pods declare required capabilities in pod.toml:

   [[capabilities]]
   name = "payment.intent"
   required = false
   risk = "high"

2. Lets hosts approve or deny per-capability requests at runtime.

3. Carries the approval state through DARTC gemmapod.ui.event CUSTOM events so the model knows what's been granted.

Planned capability families:

These will roll in over post-v0.1 minor versions. The string-set surface won't change — capability declarations and request<T> will be additive.

See also

• Runtime spec — capabilities
• Security model — capability boundaries