On this page
Integration surfaces and extension decisions
Choose the supported kind of connection
Use the dashboard for operator actions and packaged plugins for declared extensions. Read tool and plugin boundaries before granting capabilities. The existence of an HTTP route, Go type or JavaScript message does not make it a supported stable external API.
The browser uses same-origin ws:///wss:// with /ws?interaction_version=1. Server admission checks authentication/origin and can reject a protocol mismatch with a reload-required response. Treat this as release-coupled dashboard transport, not a stable REST, WebSocket, MCP or headless automation promise. Do not scrape cookies or replay private dashboard messages as an integration strategy. (I13; I14; D15)
The inspected section bridge has declared topics and commands; its wired command is project.select, and unknown/undeclared commands are refused. A successful bridge reply can mean only forwarded, not completed. It is not unrestricted tool invocation or evidence of a general browser extension API. Plugin webhook routes exist at /hooks/{plugin}/{path...}; route existence alone does not establish webhook authorization, a stable public callback contract or safe exposure. Those require plugin-specific review. (I15; I16)
Package admission, not loose scripts
The .aiiospkg verifier checks the bundle's manifest, top-level <id>-<version> directory, nonempty install-root, declared interfaces/variants, payload and entrypoint hashes, and signature objects. Package trust tiers and runtime admission are distinct from operator grants. A signature proves only the verified claim under the applicable trust roots/status, not absence of bugs. Do not drop arbitrary binaries into protected runtime directories. (I1; I2; I3)
The manifest declares ID/version, bbb_protocol_version, interfaces (ID, version, schema hash, methods), capability envelope, requirements and runtime/platform/architecture/topology variants. Optional aiios_min_version and aiios_max_exclusive_version bound host compatibility; when bounds exist an unreadable host version is refused, not assumed compatible. No host bounds does not prove future compatibility. (I3; I6)
This release requires BBB protocol version 2 in its plugin manifest and worker ABI. The worker names the aiii:bbb/bbb import module and exports including plugin-invoke, aiii-plugin-bbb-protocol-version and aiii-plugin-smoke. This is a release-specific compatibility fact, not permission to substitute any WASI/component module or a guarantee for future releases. ABI, interface/schema versions, selected runtime and host version must all be reconciled by extension maintainers. (I4; I5; I6)
Installation and verification checkpoints
With a compatible released host, authorized operator, applicable trust roots/status and sufficient storage/network access for the selected package/runtime, use the Plugins page's Install or Update action for an offered catalog entry. It selects a build for the host and stages it; a later sweep verifies/activates it subject to admission and auto-load policy. Installed, active, operational and permitted are separate states. Do not increase auto-load policy to bypass a signature failure. No package was fetched or activated in this documentation work. (I7; I8; I9 — action dispatch; auto-load UI guidance)
For maintainer offline checking, source syntax is aii plugin verify [flags] <bundle.aiiospkg> with -certifier-key, -reviewer-key, -platform-key and -trust-dir controls as applicable. Supply only approved public trust envelopes/status, not private keys. The command verifies a bundle; it does not install, grant capabilities or prove runtime readiness. There is no aii plugin install subcommand in this dispatcher. (I1)
Permissions and outcomes
plugins.grants.<plugin-id> supplies operator policy. The inspected controls include KV, memory, interactions, voice, embeddings, tools, files and read-only; outbound hosts, local access and credential handles have separate policy fields. Folder reach remains the identity sandbox (tools.extra_roots, Settings → Sandbox), not something a plugin can grant itself. Enter credentials only through the appropriate operator control; do not paste them into chat or evidence. (I10)
An operation still passes dispatch/admission and operator-grant checks. A confirmation-required operation can return a proposal without running; a proposal is not an effect receipt and should not be reissued blindly. Execution scopes carry declared effects/capabilities to the broker. The plugin response cannot author external_receipt: the host rejects that field when forged. Report a host outcome only at the strength its receipt supports; plugin success text, installation and a forwarded browser message do not independently prove an external effect. (I11; I12; I15)
Not established as stable: dashboard wire messages/HTTP routes, section commands beyond those wired, internal Go imports, unrestricted direct database access, arbitrary native plugins or universal provider compatibility. Supported integration decisions remain release- and capability-specific. Runtime replay, failure/rotation tests and technical-reader validation remain open.