Name the two modules after their software: nftables and distribution

A module's identity is the software it is (ADR 0040). Two were named after the
job instead, and the job already had a name.

firewall installs the nftables package and runs nftables.service. The seat it
claims is the-packet-filter, which is correctly named for the role. Calling the
module firewall named neither the software nor the provision, and promised that
any firewall could sit there — the false genericity the naming rule forbids.

registry runs Distribution, the OCI reference implementation, and provides
artifact-store. So registry was a third name for a thing that already had two,
which is how one word ended up meaning the module, the software and the concept
in the same paragraph.

The capability stays firewall, and correctly: a capability IS a functionality, so
a node having one and fail2ban requiring one are both right. Only the module
moves.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
This commit is contained in:
2026-09-15 20:51:00 +02:00
parent bf1f67a485
commit 71bbc7dab0
12 changed files with 3 additions and 3 deletions
+21
View File
@@ -0,0 +1,21 @@
// The firewall's own code, in the module (novox/hq ADR 0039). The mesh computes this node's whole
// rule set from every module's `listens` and writes it to /etc/nftables.conf (novox/hq ADR 0045);
// the module loads it (the nftables service, reloaded whenever the rules change). This code exists
// only to read back what is actually enforced — the enforcement itself is declarative.
import { execFile } from "node:child_process";
import { promisify } from "node:util";
const run = promisify(execFile);
export class FirewallClient {
static fromEnv(_env: NodeJS.ProcessEnv = process.env): FirewallClient {
return new FirewallClient();
}
/** The mesh's live table — exactly what is dropping and accepting on this node right now. */
async ruleset(): Promise<string> {
const { stdout } = await run("nft", ["list", "table", "inet", "mesh"]);
return stdout;
}
}
+33
View File
@@ -0,0 +1,33 @@
{
"module": "nftables",
"version": "1",
"capabilities": [
"firewall"
],
"claims": [
{
"name": "the-packet-filter",
"scope": "node"
}
],
"filtering": {
"into": "/etc/nftables.conf"
},
"resources": [
{
"id": "package",
"type": "package",
"package": "nftables"
},
{
"id": "load",
"type": "service",
"unit": "nftables.service",
"state": "running",
"boot": "enabled",
"restart-on": [
"filtering"
]
}
]
}
+14
View File
@@ -0,0 +1,14 @@
{
"name": "@novox/module-firewall",
"version": "0.1.0",
"description": "firewall — applies the mesh-computed packet filter (ADR 0045). Its diagnostic tool lives here.
"type": "module",
"private": true,
"dependencies": {
"@novox/mesh-sdk": "^0.1.0"
},
"devDependencies": {
"@types/node": "^22.0.0",
"typescript": "^5.6.0"
}
}
+19
View File
@@ -0,0 +1,19 @@
// firewall's tools — one, and the useful one: what is actually enforced. The rules are the mesh's,
// computed from every module's listens; this reads the live table so a declared scope can be checked
// against what the packet filter is really doing.
import { registerModuleTools, type ToolDefinition } from "@novox/mesh-sdk/tools";
import { FirewallClient } from "../client.js";
export function getFirewallTools(firewall: FirewallClient): ToolDefinition[] {
return [
{
name: "firewall_rules",
description: "The mesh's live nftables rules on this node — what is actually accepting and dropping.",
input: {},
run: async () => ({ ruleset: await firewall.ruleset() }),
},
];
}
registerModuleTools("firewall", () => getFirewallTools(FirewallClient.fromEnv()));
+15
View File
@@ -0,0 +1,15 @@
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"noEmit": true
},
"include": [
"client.ts",
"tools/index.ts"
]
}