jochen
6390d1d7fb
One tool runtime per node, host-side, is what the runtime was written to be; the catalogue built a container per module around it instead. This lets `serve` take a list — MESH_TOOL_MODULES as <module>=<entrypoint> entries — and do for every assigned module what it did for one: read that module's membership and follow it, serve its tools where the membership says, serve each held seat's verbs on the seat's subjects. The seats come from the memberships now, so the node's credential carries no claims; a module's own runtime still reads its credential's, so nothing built today changes behaviour. A bare path in MESH_TOOL_MODULES stays the one-module form. A bundle that throws on import is said in the log and in what `tools` answers for its module (`failed`), which discovery lists with the reason instead of as "not answering"; the other bundles serve. The filter that dropped every registration under a name but the one module goes; what stays is that a registration under a seat's name is served only where some served module claims the seat. A tool runs attributed to its module, so an event it emits lands on the module's subject and not the runtime's. MESH_OPERATOR_ACCOUNT and MESH_OPERATOR_HOME are read and said; tools take them from their environment. Proven against a real bus: three bundles, one broken; five tools and two seat verbs answer on their subjects; `tools` names the failed bundle; a membership re-issued mid-run re-serves.
mesh-tools
The Novox Mesh tool runtime — the one process per node that makes every assigned module's tools actually serve (novox/hq ADR 0175).
A module ships its tools as a bundle (built on @novox/mesh-sdk);
this runtime is what loads them and puts them on the mesh. It:
- connects the mesh bus on the node's credential — a concrete implementation of the sdk's
Brokercontract; - reads one membership per module it serves — what the mesh issued that module on this machine (ADR 0160): where its tools are answered, which seats it holds — and follows each live;
- imports each module's compiled tool entrypoints, each of which registers its tools as it loads,
guarded: a bundle that throws is named, in the log and in what
toolsanswers for its module, and the others serve; - serves every module's tools on that module's subjects and every held seat's verbs on the seat's.
Everything hard — dispatch, collection, duplicate-name safety — is the sdk's. This is the thin wrapper that binds the bus and loads the modules. Keeping the bus client here, out of the sdk, is deliberate: a bus-client change never rebuilds a module (ADR 0039). The runtime is module-agnostic: it knows bundles and subjects, nothing of what any module does. A tool that needs root escalates itself — root is the module's concern, not the runtime's.
Running it
MESH_BROKER_FILE the node's sealed credential, as the mesh delivered it
MESH_TOOL_MODULES alpha=/…/alpha/tools/index.js,beta=/…/beta/dist/index.js,…
the modules to serve and their compiled entrypoints; several entries may
name one module. A bare path is an entrypoint of the credential's own module
— the one-module form a per-module container still sets.
MESH_OPERATOR_ACCOUNT whose machine this is, and MESH_OPERATOR_HOME where their home is; set by
the mesh when the node has an account, read by tools from their environment
MESH_BROKER_URL a plain URL instead of the credential, for the bootstrap case
node dist/main.js. On a node the controller composes the variables and the host supervises the
process like any other host-side workload (novox/hq to-be 38). The container (Dockerfile) is how
a module's own service may still be built; it is no longer how tools reach a node.
mesh — the tools for whoever is on a machine
The same package carries the client (novox/hq design 25 §7, design 34): mesh tools, mesh call <module>.<tool> [json], mesh mcp (an MCP server over stdio for a program a person starts) and
mesh serve (the console: MCP over HTTP on a machine's loopback, started by the mesh as the
mesh-console module on the credential in MESH_BROKER_FILE — novox/hq ADR 0152). mesh serve
refuses to bind anything but loopback. With --console <url>, tools and call go through a console
already on the machine and need no credential.
Discovery asks the modules: every runtime answers a tools verb for each module it serves, with names,
descriptions and schemas from the code that answers them, and the console asks the catalogue which
modules the mesh holds and each module what it serves. A module that does not answer is named, never
dropped. A module may not name a tool of its own tools; the runtime refuses it at load.
Verified
npm test runs against a real NATS server with JetStream (MESH_TEST_NATS, see any test's header
for the one-line docker run) and proves the whole path over the wire: the runtime serves a
registered tool, a separate connection invokes it by name and gets the result, an unknown tool is
refused, a runtime serves exactly the subjects it is issued and re-serves on a new membership, and
the node's runtime serves three modules' bundles on one credential — one of them broken, named and
not fatal — with every seat verb answering where the membership put it.