Files
jschoubben cb2117f1c4 Issues 102–106 and ADR 0105 from the core migration
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.
2026-09-23 22:50:10 +02:00

35 lines
1.5 KiB
Markdown

---
status: open
opened: 2026-09-23
located-in: []
fixed-by:
amended-design:
---
# 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](../../02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md)). "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?