
Iii Bridge
- 7 installs
- 18.6k repo stars
- Updated August 5, 2026
- iii-hq/iii
Connect one iii engine to another over a long-lived WebSocket so functions call across the boundary via forward:/expose: aliases.
About
A skill for the iii-bridge worker that links two iii engines over a persistent WebSocket. A developer uses it to wire stable cross-engine function ids with forward:/expose:, using bridge.invoke as an ad-hoc escape hatch.
- forward:/expose: config aliases make remote functions callable as local ids
- bridge.invoke waits for return; bridge.invoke_async is fire-and-forget
Iii Bridge by the numbers
- 7 all-time installs (skills.sh)
- Ranked #3,637 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/iii-hq/iii --skill iii-bridgeAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 7 |
|---|---|
| repo stars | ★ 18.6k |
| Last updated | August 5, 2026 |
| Repository | iii-hq/iii ↗ |
What it does
Connect one iii engine to another over a long-lived WebSocket so functions call across the boundary via forward:/expose: aliases.
Files
iii-bridge
The iii-bridge worker connects this iii engine to another iii instance over iii-sdk so functions on either side can call across the boundary. It opens a single outbound WebSocket to the configured url, registers with the remote using service_id, and stays open for the engine's lifetime — bridging is request/response over that long-lived connection. There are no trigger types.
The worker is configuration-driven. The primary surface is two list-shaped config fields (forward: and expose:) that wire stable function ids on both sides; once configured, callers reach across the bridge by invoking those stable ids with the normal iii.trigger({ function_id, payload }) — no bridge-specific call shape. Two functions (bridge.invoke, bridge.invoke_async) are also registered as ad-hoc escape hatches for the rare case where the remote function id is dynamic at runtime.
When to Use
- Two iii engines need to call each other's functions over a stable, long-lived connection.
- You want a remote function to appear as a local id (
forward:) so the bridge is invisible at the call site. - You want to expose specific local functions to a remote engine (
expose:). - The remote function id is dynamic, or you are prototyping / probing connectivity — reach for the ad-hoc
bridge.invokefunctions.
Boundaries
- Prefer
forward:/expose:aliases overbridge.invoke; the escape hatches are for dynamic ids and one-offs, not the default path. bridge.invoke_asyncis fire-and-forget — it ignorestimeout_ms, returns no value, and a later remote rejection is logged but never surfaced to the caller.- Forward aliases and exposed ids are operator-wired per deployment in
iii-config.yaml; they are not stable across deployments and are documented alongside the worker config, not here. - Failures return a
FunctionResult::Failurewith a stablecode(deserialization_errororbridge_error); a successful async return only means the message was queued, not that the remote ran.
Functions
bridge.invoke— call a remotefunction_idand wait for its return value (returned directly, no envelope); honors an optionaltimeout_ms(default30000).bridge.invoke_async— hand a remote call to the WebSocket send queue and return immediately;timeout_msis ignored and no remote response is surfaced.
Both take { function_id, data?, timeout_ms? }. Reach for them only when a forward: alias is wrong or impossible; for repeated calls to the same (local, remote) pair, configure a forward: alias and call the local id instead.
Configuration
url— WebSocket URL of the remote iii instance (default${III_URL:ws://0.0.0.0:49134}).service_id/service_name— identifier (and human-readable name) registered with the remote.expose: [{ local_function, remote_function? }]— functions on this engine the remote may call;remote_functionis the path the remote invokes (defaults tolocal_function). Registered with the remote at initialize time.forward: [{ local_function, remote_function, timeout_ms? }]— local aliases that proxy outbound to a remote function. The worker registerslocal_functionon this engine so any caller reaches the remote'sremote_function;timeout_msoverrides the per-call deadline (default30000).