.dylib on macOS, .so on Linux, .dll on Windows. Once a node is registered, each of its ops appears as a button in the Console, can be a step in an OTA plan, and can run on a schedule.
Omega ships three built-in domains this way (sbom, hbom, pbom inventory). Your node uses the same model.
One contract, two calling conventions
Every node answers the same five questions. Only the mechanism differs by platform.
The five questions, in call order:
The JSON that crosses those calls is byte-identical on every platform. See Node contract for the exact shapes and the return-code rules.
The contract lives with Omega, not in your node
The interface has exactly one home, and it is the Omega repository. A node imports the contract and never redeclares it.
Do not copy
omega_node.h, omega_node.idl, or the node-abi source into your node. Reference them from a pinned Omega revision.
Lifecycle
1
Build
Compile your node for each target platform and architecture. Build a node walks through the hello node in Rust and C, and cross-compiling a Linux
.so from a Mac.2
Upload as a release artifact
Add the library to an OTA release. The platform signs the artifact’s SHA-256 with its role key.
3
Ship with a place_file step
Mark the step Register in node registry. Omega verifies the signature, lands the file under
dll/{domain}/, introspects it in a child process, and writes the node to its local registry. See Ship a node.4
Operate
The device publishes its node catalog on
node/report/registry. The Console’s Node Registry view lists the domain, version, health, and ops, with Run per op and Enable / Disable per node.Reference nodes
Both implement the same
hello domain with two ops, greet and ping, so the platform sees them identically.