Capability-provider field survey — the current option space, per class and cross-cutting

Kind: research / option-space inventory. This document makes no design decision and contains no recommendation. Each section ends with the open questions a decider would need answered. The one exception to "no verdicts": options that are verifiably dead, archived, or license-changed are flagged as such, with evidence, so nobody designs on them unknowingly.

Origin: #5686 bundled five provider targets (ESP32/MQTT, terminal, Bevy, smartphone, web) into one provider-model design. The WS-F gap pass split the filings (#5780 Android, #5781 Bevy, #5783 ESP32 platform, #5898 declaration, #5899 discovery & negotiation, #5900 grants, #5901 constrained-device, #5902 host providers: terminal & website, #5903 embedded providers: engine & smartphone, #5904 offline/degraded, #5905 security model). Drew's ruling (2026-11-04): splitting the filings is not enough — the research widening is its own task, so the design issues inherit a real option space instead of first-idea designs. This is that survey.

Method / sources: vendor and project documentation and current-state reporting, surveyed 2026-11-04. Claims carry a status inline where it matters: current versions and dates are as reported by the projects themselves. Anything I could not verify is marked [unverified]. Drew's own earlier statements in the ID design issues are treated as context for what a provider must be, per the standing raw-sources rule.

0. The shape the options are being mapped onto

From #5686, #789 (ceiling model), and the writer-set design behind #5545:

• A provider declares typed, described, versioned capabilities (name, input/output shape, units/semantics, rate/size limits, side effects) into the ceiling model: a provider can never offer more than its own ceiling, a consumer can never receive more than the grant.
• Provider identity may be the user's, the device's own, or a delegated/pseudo identity; device-owned vs user-owned vs shared/public providers all exist.
• Declaration is a signed, versioned artefact (in-repo prior art: id: F12.4 provider registry — capabilities as manifest + provider components #1061 F12.4 provider registry — capabilities as manifest + provider components; id: device.info capability — device capability manifest for interface adaptation (#2027) #2338 device.info capability manifest). Static (firmware) vs dynamic (runtime-discovered) declaration both occur.
• From the writer-set design (id: implement Writer-set view projection - view projection and discovery query (design doc) #5545): capability-bearing objects are signed, versioned, owner-controlled; ingest is a validity gate, never an authority gate — receiving and validating an object never by itself grants authority.
• Discovery (id: design: provider discovery & negotiation protocols (from #5686) #5899) happens within a world, within a server, and across bridges/federation, under visibility rules.

Every option below is described on its own terms first, then (in §6) mapped against this shape: where it fits, where it fights.

1. Terminal providers

Inherits into: #5902 (host providers: terminal & website). The terminal matters twice in ID: as a surface a user sits at, and as a provider — a shell session offers capabilities (run commands, expose command blocks with exit status, cwd, output) to authorised consumers.

1.1 Multiplexers as the programmatic substrate

1.2 Terminal emulators with remote-control APIs

• kitty — a full remote-control protocol (kitten @ … over a socket, must be explicitly enabled: allow_remote_control), plus kittens (in-terminal extensions) and two protocols of its own that other terminals adopt: the graphics protocol and the keyboard protocol. GPL-3.0.
• Ghostty — Zig core with an embeddable library (libghostty) so a host app can embed a terminal as a component rather than shell out to one; modern protocol coverage (OSC 133 etc.). MIT. The "terminal as a library" shape is unique in this class.
• iTerm2 — macOS-only; a comprehensive Python API and AppleScript surface; the deepest emulator-side API, at the cost of a platform lock. Proprietary freeware.
• VS Code terminal — xterm.js + PTY host; shell integration is built in, and extensions interact via the terminal API — but the API is editor-scoped, not a general provider surface.

1.3 The protocol layer underneath all of them: shell integration

• OSC 133 (semantic prompt / command marks, from FinalTerm) is now the de-facto standard for making shell output structured: prompt boundaries, command start/finish, exit codes. Supported by kitty, WezTerm, Ghostty, iTerm2, VS Code, foot, Zellij 0.45. OSC 7 (cwd reporting) and OSC 52 (clipboard) round out the set. This layer is what turns "a terminal" into "a provider of typed command-block events" without scraping heuristics — agent-era tools (e.g. shell-context capture in coding agents) already build exactly this three-layer stack: shell hooks → OSC 133 marks → multiplexer scrollback APIs.
• DEAD FLAG — Coder AgentAPI: a terminal-emulator-in-memory with an HTTP API for driving agents; archived 2026-09-13. Do not design on it.

1.4 Agent-protocol adjacency

Terminals are also where agents live: ACP (Zed's Agent Client Protocol) standardises editor↔agent driving; A2A (see §6.2) is agent↔agent. A terminal provider design will sit next to both — they answer "who drives the agent in the terminal", not "what capabilities the terminal offers", but the boundary must be drawn somewhere.

Open questions for the decider: Does the terminal provider expose raw PTY (bytes, maximal power, no structure) or command blocks (OSC 133-structured, typed, auditable) — or both as different capabilities with different risk classes? Is the provider the multiplexer (session outlives any surface) or the emulator (owns rendering/input)? Does Zellij's WASI-plugin shape — terminal capabilities as sandboxed components — generalise into ID's provider-component shape (#1061), or is it a local coincidence?

2. Smartphone / Android providers

Inherits into: #5780 (native Android client), #5903 (embedded providers). The platform moved under this design in the last twelve months: Android now has a first-party "apps as tool providers" mechanism.

2.1 The new platform layer: AppFunctions / "Android MCP"

• AppFunctions (Android 16+, Jetpack library): an app annotates functions; the library generates an XML schema of them; the Android OS itself keeps the registry; authorised callers discover and execute via AppFunctionManager. Callers need the EXECUTE_APP_FUNCTIONS permission. Google describes apps as behaving "like on-device MCP servers" and the layer as Android MCP; transport is Binder IPC, not HTTP. Status as of this survey: announced "officially in beta" 2026-10-31 (Android Dev Summit), Jetpack library in alpha, Gemini integration in private preview with trusted testers — the only public examples are Samsung Gallery (Galaxy S26) and Gemini's Calendar/Notes/Tasks integrations. Docs still say "experimental feature"; access to the full pipeline is limited to a limited set of apps and system agents during evaluation.
• What it is for ID: this is the first time the operating system offers the declaration+discovery half of a capability-provider model on a phone — but the registry is the OS's, the caller set is Google's, and authority is Android permissions, not owner-controlled signed objects. It is an instantiation surface, not the model.
• Third-party precedent: Phone MCP (Premex, open source): an Android app that turns the phone into a real MCP server (photos, sensors, camera, contacts) reachable via an outbound-connection relay or directly on local Wi-Fi — evidence that the phone-as-provider demand exists independent of Google's programme, and that a relay pattern solves carrier/NAT reachability.

2.2 The classic platform surfaces (mature, no programme gate)

• Intents / App Links / bound services (AIDL): the original Android capability system — implicit/explicit intents as coarse capability calls, App Links as verified web↔app delegation, bound services as the typed IPC variant. Mature, Apache-2.0 (AOSP), but granularity is app-level and consent is install/permission-time, not per-grant.
• Runtime permissions + per-use consent: Android's permission model (dangerous permissions, one-time grants, photo-picker-style mediated access) is the closest mainstream analogue to ID's per-use consent caps (id: loc.* capability — position/watch with an accuracy ceiling and per-use consent (#2027) #2341's accuracy-ceiling + per-use consent shape).
• Accessibility services: the de-facto "drive any app" capability — powerful enough that Play policy restricts it; a provider built on it inherits the policy fight.
• WorkManager / foreground services: the honest background-execution envelope (battery rules) any provider must declare against — id: design: native Android client — identity custody, offline worlds, full client (extends the #1831 PoC) #5780 already flags this.

2.3 On-device runtimes and agents

• Termux: a full Linux userland on the phone — the "phone as a small server" variant. Caveat: the Play Store build is years stale; distribution is F-Droid/GitHub [widely reported; verify current state before relying].
• On-device agent runtimes: Gemini Nano with native function calling and ML Kit's Agentic API (alpha, Oct 2026) run an agent loop on the device — the phone as consumer-host, not just provider.
• Wasm on Android: Wasmtime and other runtimes have Android targets [uneven maturity across runtimes — unverified per-runtime]; relevant if provider components (id: F12.4 provider registry — capabilities as manifest + provider components #1061) are to run on the phone in the same component shape as elsewhere.

Open questions for the decider: Does ID's Android client register its capabilities with the OS registry (AppFunctions) as one projection of its writer-set declarations — accepting Google's caller gating — or stay self-contained and treat AppFunctions as an interop bridge for other apps' functions? How do Android runtime permissions compose with ID grants (permission held by the app ≠ grant held by a consumer)? What wakes a provider on a phone (push, WorkManager windows) given #5904's offline/degraded model?

3. Web / browser providers

Inherits into: #5902 (host providers), #5782 (GUI surface). This class changed the most in 2026: the web platform is growing a native "page as tool provider" API.

3.1 WebMCP — pages declaring tools to agents

• WebMCP (W3C Web Machine Learning Community Group; editors from Microsoft and Google): a page calls document.modelContext.registerTool() with a name, description, JSON Schema, and an execute callback; a declarative form annotates HTML forms into tools. Tools run in the page, in the user's session, visibly. It borrows MCP's vocabulary but is not MCP: no server process, no JSON-RPC transport, tools exist only while the tab is open. Cross-origin exposure needs explicit grants both ways (exposedTo / fromOrigins); everything is gated by the tools Permissions Policy (default 'self'); annotations include readOnlyHint, untrustedContentHint, consequentialHint — hints, not enforcement.
• Status: Draft Community Group Report (current draft 2026-10-20) — not a W3C standard; Chrome origin trial from Chrome 149; Mozilla's standards position neutral, WebKit's oppose. Chrome's own guidance: WebMCP is the contextual layer, backend MCP is the service layer; neither replaces the other.
• For ID: a website-as-provider gets a platform-native declaration surface for the first time — but declaration honesty and authority stay the page's problem, which is precisely the half ID's writer-set model exists to own.

3.2 The extension route (works today, every browser)

• WebExtensions (Manifest V3): an extension can expose page + browser capabilities (tabs, storage, scripting, native messaging to a local host process). MV3's service-worker lifecycle and the removal of blocking webRequest are real constraints on provider shape. Cross-browser baseline is good for core APIs, uneven at the edges. An extension is today the only way to ship a browser provider to all users without an origin trial.
• Native messaging: the extension↔local-process bridge — the seam where a browser provider meets a local ID node.

3.3 Browser device & platform APIs (Chromium-led)

• WebUSB, WebSerial, Web Bluetooth, WebHID: a web page as a hardware capability provider (talk to an ESP32 over serial from a tab, etc.) — Chromium-only in practice; Firefox/Safari do not ship most of these. File System Access, WebGPU, WebNN similarly expand what a page can offer. These make "website" and "ESP32" provider classes touch: the browser is a provisioning/bridge surface for constrained devices.

3.4 Browser-automation MCP servers (the inverse direction)

• chrome-devtools-mcp, Playwright MCP and kin expose the browser itself as tools to an external agent — the browser as provider to agents rather than pages as providers to the browser's agent. Both directions now exist in the field; a web-provider design has to say which one it means, or both.

3.5 Adjacent: MCP Apps

• MCP Apps (first official MCP extension, SEP-1865, stable 2026-01-26): MCP servers return interactive UI surfaces rendered in sandboxed iframes inside clients — providers that bring their own UI. Directly relevant to id: design: graphical client & tooling surface — windowing, world inspector, debug UI #5782's surface design: the field's answer to "a provider with a GUI" is server-declared UI in a sandbox, not provider-supplied native UI.

Open questions for the decider: For a website provider, which declaration is authoritative — the writer-set object, with WebMCP registration as its in-tab projection? Does ID consume other sites' WebMCP tools as foreign providers (ingest = validity gate) — and what does WebKit's "oppose" do to a cross-browser story? Are Chromium-only device APIs acceptable as a provider substrate given ID's own browser fleet is Chromium-based?

4. Game-engine providers (Bevy)

Inherits into: #5781 (Bevy incorporation), #5903 (embedded providers). Bevy is both a provider target (engine offers render/input/audio surfaces) and a client shape (a world hosted in an engine).

4.1 The engine itself

• Bevy (0.20 current per ecosystem compat tables, late 2026): Rust, data-oriented ECS at the core, MIT OR Apache-2.0. Fast release cadence with breaking changes per release — every ecosystem crate pins to a Bevy version (this is the version-policy question id: design: Bevy incorporation — ID worlds as Bevy applications (ECS mapping of the entity/triple model) #5781 already poses). An official editor is under active development [status unverified in detail].
• bevy_ecs standalone: the ECS is usable without the engine — including, per Espressif's own developer portal, Bevy ECS running on an ESP32 in no_std Rust. The class boundary between "engine provider" and "constrained device" is thinner than the issue split assumes; the mapping ID entities↔Bevy entities could in principle run on the device class too.

4.2 Scripting / provider components inside the engine

• bevy_mod_scripting (0.21–0.23 line, actively released through Oct 2026): the community scripting bridge — Lua and Rhai supported (via mlua / rhai), bindings generated from Bevy's reflection, dynamic systems/components registerable from scripts. Self-described work-in-progress with anticipated API churn; version-locked to Bevy patch releases. FLAG: Rune support is "temporarily on hold" in the rewrite — do not assume it.
• The engine-native alternative is plugins in Rust (Bevy's own plugin architecture): full power, compile-time only — providers as native code vs providers as scripts is a live axis here, not a settled one.

4.3 Networking / replication (world state across engines)

• lightyear (0.31 for Bevy 0.20): the full-featured option — client-server and P2P and host-client modes, prediction/interpolation, multiple transports (UDP, WebSocket, WebTransport via aeronet, Steam), deterministic (input-only) replication supported. Built on bevy_replicon.
• bevy_replicon alone: the replication core (world replication, interest management, pre-spawning) without lightyear's netcode opinions — the "bring your own transport" variant.
• aeronet: the transport-abstraction layer both sit on.
• ID-relevant tension: these systems replicate engine state under a server-authoritative or lockstep model; ID replicates a journal under a writer-set model. They are answers to different authority questions and a design must not conflate them.

4.4 Variants outside Bevy

• Fyrox (MIT, Rust): a full engine with an editor — the "batteries included" Rust alternative; smaller ecosystem.
• Godot + godot-rust (gdext) (MIT): the non-Rust-core engine with a live Rust binding story; huge community, different (node/scene) state model.
• macroquad / miniquad (MIT/Apache): minimal Rust game loops — if the "engine" need is really "a render/input surface", these are the floor of the class.
• Unity/Unreal exist as proprietary poles; noted for completeness, they do not fit a Rust workspace's seams.

Open questions for the decider: Is the Bevy provider face (render/input/audio surfaces) declared through the same manifest as every other provider, with the engine-specific part confined to how surfaces are produced? Engine-state replication (replicon/lightyear) vs journal replication (ID): which carries a shared world when both are present — and can replicon-style interest management inform #5899's discovery visibility? Bevy's cadence: pin, track, or abstract (already open in #5781 — the ecosystem's universal version-pinning is evidence, not an answer).

5. ESP32 / MQTT / IoT providers

Inherits into: #5783 (ESP32 platform line), #5901 (constrained-device providers), and the existing bridge design #2343 (id.device.v1 MQTT bridge). Two independent axes: what runs on the device, and what the device speaks.

5.1 On-device stacks

5.2 What the device speaks

• MQTT 5.0 / 3.1.1 — the incumbent (id: MQTT device bridge id.device.v1 — spec + labelled PoC (ESP32 path recommendation) (#2027) #2343's bridge is specified against it). Client side: ESP-IDF's built-in esp-mqtt; Rust side: rumqttc (client) / rumqttd (broker), paho bindings; no_std clients exist at smaller scale (mqttrs-based). MQTT 5's user properties and response-topic patterns are the hooks a capability-envelope design would use.
• MQTT-SN — the UDP/sleepy-device variant; niche but designed exactly for the power posture id: design: ESP32 hardware platform line — boards, provisioning, firmware lifecycle, OTA, power #5783 worries about.
• Matter over Thread/Wi-Fi — the industry-consortium model: production-ready on ESP32-C6/C5 (802.15.4 radios) via Espressif's esp-matter SDK; Thread 1.3/1.4; Home Assistant / Apple / Google fabrics interoperate today. Two honest caveats from the field: esp-matter's OTA is not fully wired up (reflash by hand), and Matter's device-type model is rigid — custom capabilities need custom clusters or don't map. Matter also brings its own identity/attestation regime (DAC certificates, CSA certification for distributed products) — a second authority system any design must reconcile with ID's device-owned identity (design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686's question), not a transport you bolt on.
• CoAP / LwM2M — the carrier/industrial lineage: CoAP (REST on UDP, DTLS) and LwM2M (device management + object-model telemetry). Less consumer gravity, more fleet-management shape (bootstrap, firmware objects) — LwM2M's object model is a worked example of "declared device capabilities" from the telecom world.

5.3 Broker side (where the bridge terminates)

Open questions for the decider: Which wire does the capability semantics ride: MQTT topics/payloads per #2343, with Matter as a foreign-provider interop — or is Matter a second native instantiation of the provider model (its cluster model ≈ capabilities, its attestation ≈ declaration honesty)? For firmware: does the crate split's embedded variant (#5788) target esp-hal/Embassy Rust or ESP-IDF, given the OTA/rollback and 64 KiB frame budget questions in #5783? Broker: is the bridge's broker a component ID operates (in-Rust rumqttd? Mosquitto?) or an external the bridge merely speaks to?

6. Cross-cutting: the layer above the classes

Inherits into: #5898 (declaration), #5899 (discovery), #5900 (grants), #5905 (security model), #5545 (writer-set shape). Four families: agent-tool protocols, component/sandbox systems, object-capability RPC, and capability-token formats. They are not interchangeable — each owns a different layer, and the survey's main cross-cutting finding is that the field has separated into exactly those layers.

6.1 Agent-tool protocols: MCP (and A2A next to it)

• MCP — current spec revision 2026-07-28: JSON-RPC 2.0; transports stdio and Streamable HTTP; primitives tools/resources/prompts; the 2026-07-28 revision made the core stateless (no initialize handshake, no session header), deprecated Sampling/Roots/Logging, and formalised an extensions framework (MCP Apps UI extension stable 2026-01-26; Tasks extension for long-running work). Governance moved to the Agentic AI Foundation (Linux Foundation) in Dec 2025. Authorization, where present, is an OAuth 2.1 profile (protected-resource metadata, audience-bound tokens). The spec is explicitly silent on policy, quota, and audit — hosts decide.
• Fit with ID's shape: MCP is a declaration + invocation surface: tools/list ≈ a declaration read, tool calls ≈ invocations. Its stateless 2026 core fits a journal-based world better than its sessionful predecessors did. As a provider mouth — an ID provider projected as an MCP server, and foreign MCP servers ingested as providers — it composes cleanly with "ingest is a validity gate": schema-valid ≠ authorised, and the spec never claims otherwise.
• Fight: MCP's authorization story is identity-and-token centric (OAuth bearer authority, ambient once granted). ID's authority lives in owner-controlled signed objects under a ceiling model. Any design that lets an OAuth token be the authority has replaced ID's model, not interfaced with it; the grant check has to stay in the writer-set layer (id: design: capability grants for providers (from #5686) #5900) with MCP as transport. Also: MCP's consumer is assumed to be an agent host; ID's consumers are arbitrary authorised parties — human clients included.
• A2A (v1.0 stable 2026, also AAIF): agent↔agent task delegation with Agent Cards. Adjacent, not a provider protocol — it answers "agent hires agent", and would sit above a provider layer, not replace it. (Name-collision warning: Zed's editor protocol is also "ACP"; IBM's Agent Communication Protocol was folded into A2A in 2025. Cite carefully.)

6.2 The component model: WASI / WIT and the sandbox hosts

• WASI + Component Model — WASI 0.2 (Component Model + WIT) is stable and widely implemented; WASI 0.3 (2026) adds native async (futures/streams in the canonical ABI). Wasmtime is the reference runtime (Bytecode Alliance, Apache-2.0, 2-year LTS lines). WIT gives typed interfaces — records, variants, resource handles — i.e. a declaration language for components. Components receive exactly the host interfaces they are linked against: capability-style by construction at the sandbox boundary. Threading remains the notable gap.
• Runtime variants: wasmi (interpreter, tiny footprint — the constrained-host variant), Wazero (Go, zero-dependency), Wasmer (commercial-backed, broader language SDKs). Same components, different host economics.
• Extism (BSD-3): a host-embedding framework over multiple engines with a simple bytes-in/bytes-out plug-in ABI and custom host functions as the capability surface — the pragmatic "providers as plug-ins with only granted host functions" shape, production-used.
• wasmCloud (CNCF incubating, Apache-2.0): the distributed-systems variant — components + host "providers" for capabilities (messaging/KV/HTTP) linked by signed link definitions over NATS; shipped 2.8 in Aug 2026. FLAG (health, not death): LFX health score "Concerning" (49/100), contributor counts down ~25% year-over-year — active, but a thinner maintainer bench than its CNCF status suggests; weigh accordingly.
• Fit with ID: the component model is the strongest candidate shape for provider components (id: F12.4 provider registry — capabilities as manifest + provider components #1061's "provider components" made literal): a provider implementation as a component whose WIT interface is its declared capability shape, holding only granted host capabilities. Zellij (§1.1) already proves this shape inside one product.
• Fight: WASI capabilities govern what code may do inside a sandbox. They are not delegable grant objects between principals: no attenuation chains, no owner-controlled signed artefacts, no revocation story across a network. The component layer can enforce a grant; it cannot be the grant system (id: design: capability grants for providers (from #5686) #5900 stays ID's).

6.3 Object-capability RPC: Cap'n Proto / CapTP

• Cap'n Proto (1.5.0, Jul 2026; MIT): zero-copy serialization + an RPC system whose security model is CapTP (from the E language): authority is possession of an unforgeable object reference; delegation = handing over a reference; attenuation = handing over a proxy/facet that forwards only some methods; promise pipelining and disconnect handling are protocol-level. Reference implementation supports CapTP level 2 (3-party handoff is the unfinished level) [per project docs; unchanged for years]. Production home: Cloudflare Workers internals / Sandstorm lineage.
• Fit: philosophically the closest system in the field to ID's least-privilege grant model — "no ambient authority" is its founding axiom, and facets are attenuation as a programming pattern, not a policy bolt-on.
• Fight: CapTP references are live, connection-scoped objects; ID's grants are persistent, signed, versioned artefacts in a journal that must survive offline, sync, and audit (id: design: offline & degraded operation for providers (from #5686) #5904). CapTP offers runtime discipline for a live provider session; it cannot serve as the grant ledger. Also honest adoption note: outside its niche, Cap'n Proto RPC remains rare — the ecosystem gravity is Protobuf/gRPC's, and the ocap discipline would be carried by ID alone.

6.4 Capability tokens: the grant-object formats

The layer that does deal in persistent, delegable, attenuating authority artefacts:

• Fit/fight summary for §6.4: these formats are grant-shaped, so the question is inverted — not "can they express ID's grants" but "what does ID's writer-set object add that they lack": journal integration, world-scoped visibility/discovery, versioning under owner control, and the ceiling model. A design could adopt a token format as the encoding of grant objects, or keep ID's objects and borrow the attenuation/subsumption rules. Either way the survey fact stands: attenuate-only delegation with offline verification is a solved, multiply-implemented pattern in 2026 — ID does not need to invent it, only to choose its encoding and its deltas.

6.5 Embedded scripting as provider logic

• Lua (MIT; via mlua in Rust) and Rhai (MIT OR Apache-2.0; Rust-native, designed for embedding with host-controlled exposure) are the live pair — proven inside Bevy (§4.2) and across the tooling field. QuickJS (MIT) is the JS-shaped variant. The pattern that matters: scripts receive a host-curated API surface — capability discipline by API design rather than by sandbox. Weaker isolation than Wasm components, far lower integration cost; the two are complements at different trust levels, not rivals.

6.6 Identity plumbing (adjacent, not authority)

• SPIFFE/SPIRE (CNCF graduated): workload identity via attested SVIDs — answers "which workload is this provider process" for the host side. Like OAuth, it identifies principals; it does not express owner-controlled grants. Relevant to id: design: provider security model (from #5686) #5905 as the identity layer a provider host might present, never as the grant itself.

6.7 The cross-cutting picture

The field in 2026 has converged on a layered shape, whether or not any single stack admits it:

1. Declaration/discovery surface — MCP tools/list, AppFunctions' OS registry, WebMCP registration, WIT interfaces, Matter clusters, id: device.info capability — device capability manifest for interface adaptation (#2027) #2338-style manifests.
2. Invocation transport — MCP (stdio/HTTP), Binder, MQTT, CapTP, in-process component calls.
3. Sandbox/enforcement — WASI components, Extism hosts, browser origins, Android permissions.
4. Authority artefacts — writer-set objects (ID), UCAN/Biscuit/macaroon tokens, OAuth tokens (identity-centric pole).

ID's model, as filed, puts its originality in layer 4 and its projection discipline (the same declaration projected onto many surfaces). Every option above can be located in exactly one or two layers — the design risk the split issues should watch is importing a layer-1/2/3 system and accidentally inheriting its layer-4 assumptions (MCP+OAuth being the standing example).

Open questions for the decider: Which single layer does each split issue own, and which does it borrow? Is there exactly one grant-object format (ID's writer-set objects) with projections (UCAN/Biscuit encodings, MCP surfaces), or are foreign grant formats ingestible as first-class? Does the provider-component runtime (if any) standardise on the component model now, or stay interface-only until a second implementation forces the question?

7. Flag summary — dead, changed, or thinner than they look

8. What this survey deliberately did not do

• No option was benchmarked, prototyped, or load-tested; maturity claims are the projects' own plus adoption signals, marked as such.
• iOS was out of scope (the filed class is Android, id: design: native Android client — identity custody, offline worlds, full client (extends the #1831 PoC) #5780); the AppFunctions/WebMCP pattern has no public iOS counterpart at survey time [unverified — no survey pass made].
• No recommendation is made or implied. Where one option is "the default" or "the incumbent", that is a statement about the field's centre of gravity, offered so the decider knows what choosing otherwise costs.

Cross-links: parent bundle #5686 · splits #5780, #5781, #5783, #5898, #5899, #5900, #5901, #5902, #5903, #5904, #5905 · writer-set #5545 · ceiling model #789 · registry prior art #1061, #2338 · MQTT bridge #2343 · build variants #5788 · GUI surface #5782.

Acceptance criteria

• Every provider class named in design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 (ESP32/MQTT, terminal, Bevy, smartphone, web) has a survey section, plus the cross-cutting frameworks section.
• Each option lists current variants/status with evidence (repo/registry links, last-release or archival state).
• Options that are verifiably dead, archived, or license-changed are flagged as such with evidence, per the issue's one-verdict exception.
• Each section ends with the open questions a decider would need answered; the document makes no design decision and no recommendation.