jschoubben
cb2117f1c4
Two birth-address outages and a registry that would have been the third; a container that keeps a stale environment after its file changes; a host command that applied a converged declaration to an adopted node; the hub and the vault without seats. And the decision the operator made under it all: the hub adopts the predecessor's tunnel in place, key and peers and range and port.
1.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-23 |
105 — The hub of the private network is a placement, not a seat
What was observed
Reading the registry of a one-node mesh, 2026-09-23. The private network claims a seat,
the-private-network, scoped to the node — because every node has an interface and a
mesh-scoped seat would refuse the second machine. The fact that matters, which node is the hub the
others rendezvous at, is a placement record (overlay place <node> hub) and no seat at all.
Why it matters beyond this instance
The four foundation seats all say the same thing: there is exactly one of me in this mesh (ADR 0079). "There is exactly one hub" is that shape. As a placement it is refused by nothing: two nodes can be placed as hub, and the mesh would compute a graph with two rendezvous points and say nothing.
It also confuses the reading. Asked "who provides the private network", the registry answers with a node-scoped seat held by every node, which is true and not what was asked.
Open questions
- Should the hub be a mesh-scoped seat —
the-hub, or the network's own name — claimed by the node that is placed there, refused elsewhere? - Does the per-node seat still say anything once the hub is a seat, or is it the interface's presence restated?
- What else in the mesh is "exactly one" and recorded as a placement rather than a seat?