The network carries the registry trust (ADR 0082, issues 042/048/062) #29

2026-09-17T22:25:30Z

jschoubben commented

2026-09-17 22:25:30 +00:00

Being on the private network is what grants a machine the right to pull from the mesh's artifact store in the clear (novox/hq ADR 0082), so the networking module now writes the runtime's trust — a daemon.json naming the store by its internal name — and restarts the runtime once when the fact first lands.

Three commits, each proven by the built-store-cross-node bed:

The network carries the registry trust — the overlay generator emits the trust file and its reload when a module serving artifact-store is assigned to a machine on the network; nothing is written when the mesh has no store (hq issues 042/048).
The restart-on rename reads both list shapes — resources composed in code carry restart-on as []string; the rename only read []any, so the reload's reference pointed at nothing and the runtime kept serving without the trust its daemon file already carried (bed run 8).
An artifact-store lookup failure refuses the compose — a failed inventory read composed the network without the trust under a push that reported success; "no store" now only ever means the mesh has none (hq issue 062, bed run 11).

Validated: full unit suite green; built-store-cross-node green fresh (run 12: mesh-controller 98aea8b, mesh-catalog 1891b09, mesh-lab cb353f9) — node2's consumers open the store and broker the mesh built and adopted, over the overlay.

Being on the private network is what grants a machine the right to pull from the mesh's artifact store in the clear (novox/hq ADR 0082), so the networking module now writes the runtime's trust — a daemon.json naming the store by its internal name — and restarts the runtime once when the fact first lands. Three commits, each proven by the built-store-cross-node bed: - **The network carries the registry trust** — the overlay generator emits the trust file and its reload when a module serving `artifact-store` is assigned to a machine on the network; nothing is written when the mesh has no store (hq issues 042/048). - **The restart-on rename reads both list shapes** — resources composed in code carry `restart-on` as `[]string`; the rename only read `[]any`, so the reload's reference pointed at nothing and the runtime kept serving without the trust its daemon file already carried (bed run 8). - **An artifact-store lookup failure refuses the compose** — a failed inventory read composed the network without the trust under a push that reported success; "no store" now only ever means the mesh has none (hq issue 062, bed run 11). Validated: full unit suite green; built-store-cross-node green fresh (run 12: mesh-controller 98aea8b, mesh-catalog 1891b09, mesh-lab cb353f9) — node2's consumers open the store and broker the mesh built and adopted, over the overlay.

jschoubben added 3 commits 2026-09-17 22:25:30 +00:00

The network carries the registry trust (ADR 0082, issues 042/048) 0e9035d479

Being on the private network is what grants a machine the right to pull from the mesh's
artifact store, so the module that puts a machine on the network writes the runtime's
trust — a merged /etc/docker/daemon.json naming the store's internal name under
insecure-registries, and a docker.service restart when that fact first lands. The registry
speaks plain HTTP because every path to it is already inside the overlay's encryption; the
provider is found, not configured — whichever module serves artifact-store, on whichever
machine holds it — and with no store on the network nothing is written, which is genesis.

https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx

The restart-on rename reads both list shapes bc289cbe04

A resource composed in code carries restart-on as []string; the rename
only read []any, so the overlay's registry-trust reload kept its bare
reference, pointed at nothing, and the runtime was never restarted —
the trust was on disk and not in the daemon, with every check passing.
Diagnosed on the built-store-cross-node bed, run 8 (issues 042/048).

An artifact-store lookup failure refuses the compose 98aea8b25c

artifactStoreOnNetwork collapsed a failed inventory read into 'no
store', so a hiccup composed a declaration without the registry trust,
delivered by a push that reported success — and nothing recomposed the
machine until the next push. Seen once in three fresh runs of the
built-store-cross-node bed (run 11). Refused loudly instead: 'no store'
now only ever means the mesh has none.

jschoubben merged commit 9c718025c0 into main

2026-09-17 23:00:37 +00:00

jschoubben referenced this pull request

2026-09-26 21:40:12 +00:00

The controller marks a deliberately-empty declaration owns_nothing (hq 127) #78

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#29