jschoubben
04a689e008
A module reads its broker credential from MESH_BROKER_FILE — the sealed
{url,fingerprint} the mesh delivered — and connects over amqps pinned to
exactly that certificate. The pin is two-phase (fetch cert, verify, then
trust only it), because Node's checkServerIdentity does not run under
rejectUnauthorized:false, so a naive connect-then-check would already have
sent the password to whoever answered.
A scoped module (assumeExchanges) never declares the exchanges (its account
may not) nor its own queue with a dead-letter (the broker refuses that to a
non-administrator) — the mesh pre-declared the queue, so it passively checks
it, binds and consumes. The RPC reply queue is lazy, and a module that
registered no tools serves none: a pure-events consumer touches only what its
account allows.
Verified end-to-end against a real broker as the scoped account: the audit
logger consumes # and records events, over an account that is not the
broker's own.
Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
mesh-tools
The Novox Mesh tool runtime — the per-node process that makes a module's tools actually serve.
A module ships its tools (built on @novox/mesh-sdk); this
runtime is what loads them and puts them on the mesh. It:
- connects the mesh broker (novox/hq ADR 0001) — a concrete AMQP implementation of the sdk's
Brokercontract; - imports the assigned modules' compiled tool entrypoints, each of which registers its tools as it loads;
- serves them through the sdk's
serveToolsharness, answeringtools.invokeover the broker.
Everything hard — dispatch, collection, duplicate-name safety — is the sdk's. This is the thin wrapper that binds the broker and loads the modules. Keeping the AMQP client here, out of the sdk, is deliberate: a broker-client change never rebuilds a module (ADR 0044).
Running it
MESH_BROKER_URL amqp://… the mesh broker
MESH_TOOL_MODULES /a/tools/index.js,… the assigned modules' compiled tool entrypoints
node dist/main.js, or the container (Dockerfile). On a node the host resolves both variables
and starts it like any other supervised workload.
Verified
npm test stands up LavinMQ (the mesh's broker) and proves the whole path over real AMQP: the
runtime serves a registered tool, a separate connection invokes it by name and gets the result, and
an unknown tool is refused over the wire.