Record why the module's own secret is named for whose it is

The field was called needs, beside secrets, and both were name-to-path holding
something secret. What separates them is whose, not how secret — so that is
what the name says now.
This commit is contained in:
2026-08-31 13:47:21 +02:00
parent aafeb5c9df
commit a036bac47b
+22 -1
View File
@@ -230,7 +230,8 @@ A database has a superuser password, a broker an administrator, a registry an ac
them is *for* anybody** — they are not the credential a consumer is given, and the mechanism that them is *for* anybody** — they are not the credential a consumer is given, and the mechanism that
hands those out has a consumer in the middle of it. hands those out has a consumer in the middle of it.
So a module says what it needs and where to put it, and the mesh generates one **per node**, So a module says what it needs and where to put it — `own-secrets`, keyed by a name of the
module's choosing — and the mesh generates one **per node**,
seals it to that machine and reads it no more than it reads any other secret. Per node seals it to that machine and reads it no more than it reads any other secret. Per node
deliberately: a module running on three machines has three passwords, where one in the manifest deliberately: a module running on three machines has three passwords, where one in the manifest
would put the same secret on every machine that ever runs it, in a file anybody can read, for ever. would put the same secret on every machine that ever runs it, in a file anybody can read, for ever.
@@ -240,6 +241,26 @@ Remade when the machine's sealing key changes. **Declared and not made is refuse
module whose own credential is silently absent starts, fails to authenticate, and the reason is module whose own credential is silently absent starts, fails to authenticate, and the reason is
three layers from the machine reporting it. three layers from the machine reporting it.
### It is named for whose it is, not how secret it is
*2026-08-31, from an audit asking whether the manifest format was becoming hard to hold in the
head.*
The field was called `needs`, beside `secrets` — which is where a **provision's** credential lands
on a consumer. Both were name-to-path, both held something secret, and the names distinguished
them not at all. **Reaching for the wrong one parsed cleanly and failed somewhere else entirely**,
which is the shape of fault this whole design exists to prevent, sitting in the manifest format.
The axis that separates them is not how secret they are — both are — but **whose**:
| | keyed by | belongs to |
|---|---|---|
| `secrets` | the provision it is for | the relationship with another machine |
| `own-secrets` | a name the module chose | this module, and nobody else |
**A manifest using the old name is told the new one** rather than refused with "unknown field".
Whoever wrote it knew what they meant, and the mesh knows what it is called now.
### Some of them the mesh cannot make ### Some of them the mesh cannot make
*2026-08-31, from making the builder a module — the first thing to hold one.* *2026-08-31, from making the builder a module — the first thing to hold one.*