2.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |||
|---|---|---|---|---|---|---|---|
| located | 2026-09-23 |
|
|
106 — The vault claims no seat, so nothing refuses a second one
What was observed
Reading the registry, 2026-09-23. The vault provides secret to the whole mesh and claims no
seat. The store, the broker, the controller and the catalogue each claim one, named after
themselves, so that a second claimant is refused at resolution
(ADR 0079). The vault
was added after that record and did not inherit the rule.
Why it matters beyond this instance
The vault holds every credential the mesh mints. A second vault, assigned by mistake or by a module
that provides secret itself, would answer requirements the first was answering, and nothing in
resolution would object. Of all the components to allow two of silently, this is the one to allow
least.
The rule is already written; this is an instance it was not applied to. Worth asking whether others were missed the same way — every provider added after 0079.
Open questions
- A mesh-scoped seat
mesh-vault, by the 0079 convention — is there any reason not to? - Should a provider of a mesh-scoped provision be required to claim a seat, or say explicitly that more than one is allowed, so the omission cannot recur?
Decided, 2026-10-01
ADR 0161, rule 1: mesh-vault joins the mesh's
own set, mesh-scoped, delivering secret, and the vault claims it; a second provider is a second
claimant, refused by name. The record also answers the second question: a provision the mesh's own
code dereferences by name gets a seat, every other mesh-scoped provision may have several providers.
Design 26's reserved for secret named an effect no rule produced; corrected there.