Supersedes 0032, which decided the right thing and described it wrongly. The decision is unchanged: the account that installed the host owns the mesh, and there is no user model. What was wrong was inventing "a surface that delegates authentication" for the board. It is a web application with a login, in the way every web application has a login. That is a fact about an application, not a property of the mesh. The cost was not cosmetic. It made the identity module look like part of the mesh's authority — something the mesh depends on to know who anybody is — when the mesh knows nothing about people at all and one of the applications running on it happens to have a login. Keeps the line that is worth writing down, and states it more plainly: signing in to an application must not become authority over the mesh. Today it cannot, because the board reads and does not act. The moment it can assign a module, whoever it lets in has mesh authority — and it would arrive as a feature rather than as a decision. So a surface that can change the mesh is a change to who owns the mesh, and is taken as one. Not forbidden; just not something that turns up in a pull request titled "add assign button".
82 lines
4.0 KiB
Markdown
82 lines
4.0 KiB
Markdown
---
|
|
topic: how we work
|
|
status: accepted
|
|
date: 2026-08-31
|
|
deciders: jochen
|
|
reconstructed: false
|
|
supersedes: 02-DECISIONS/0032-the-local-account-owns-the-mesh.md
|
|
---
|
|
|
|
# 34. The local account owns the mesh, and a web application's login is not that
|
|
|
|
*Supersedes [ADR 0032](0032-the-local-account-owns-the-mesh.md), which decided the right thing and
|
|
described it wrongly. The decision below is unchanged; what it said about the board was an
|
|
invention.*
|
|
|
|
## Context
|
|
|
|
ADR 0032 answered *who owns the mesh* — the account that installed the host — and then framed the
|
|
board as **a surface that delegates authentication**, a category it made up for the occasion. It
|
|
does not need one.
|
|
|
|
**The board is a web application.** It has a login, provided by the identity module, in the way
|
|
every web application has a login. That is a fact about an application, not a property of the
|
|
mesh, and giving it a name in the mesh's vocabulary implied a relationship that is not there.
|
|
|
|
The cost of the invented category was not cosmetic. It made the identity module look like part of
|
|
the mesh's own authority — something the mesh *depends on* to know who anybody is — when the truth
|
|
is that the mesh knows nothing about people at all, and one of the applications running on it has
|
|
a login.
|
|
|
|
## Decision
|
|
|
|
**The account that installed the host owns the mesh on that node.** Authority is a local login.
|
|
There is nothing else to hold, no user model, no roles, and nothing to administer.
|
|
|
|
**This follows from what was already decided.**
|
|
[ADR 0004](0004-a-node-and-how-it-joins.md) says there is no authorisation between nodes — every
|
|
node is the operator's own, so a message from one is a message from them, and *the mesh boundary
|
|
is the security boundary.* A user model inside that boundary would guard nothing: anyone it could
|
|
stop could read the node's key off the disk.
|
|
|
|
**A web application's login is its own business.** The board authenticates its users through the
|
|
identity module. So might anything else the mesh runs. **None of that is mesh authority**, and the
|
|
mesh does not learn who anybody is from it.
|
|
|
|
## The line this draws, which is the reason to write it down
|
|
|
|
**Signing in to an application must not, on its own, become authority over the mesh.**
|
|
|
|
Today it cannot: the board reads and does not act
|
|
([`11-a-board.md`](../03-DESIGN/01-to-be/11-a-board.md) — *not the way to change things*). Looking
|
|
at a page tells you what is true and changes nothing.
|
|
|
|
**The moment the board can assign a module, whoever it lets in has mesh authority** — and it would
|
|
arrive as a feature rather than as a decision. That is the failure this record exists to make
|
|
visible, because it is the kind that is only obvious afterwards.
|
|
|
|
So: **a surface that can change the mesh is a change to who owns the mesh**, and is taken as one.
|
|
Not forbidden — wanting to manage nodes from a browser is reasonable — but not something that
|
|
turns up in a pull request titled *add assign button*.
|
|
|
|
## Consequences
|
|
|
|
**The identity module is not special.** Not substrate ([ADR 0031](0031-the-control-plane-authenticates-nobody.md)),
|
|
not part of the mesh's authority, and nothing about the mesh stops working when it is down. Some
|
|
applications cannot be logged into, which is what it means for an application's login provider to
|
|
be unavailable.
|
|
|
|
**Anyone with a shell on a node has full authority there.** Unchanged from ADR 0032, and still the
|
|
sentence that decides who gets an account on a machine. The protection is the machine's own login
|
|
and the overlay that keeps it unreachable from outside ([ADR 0007](0007-connectivity.md)).
|
|
|
|
**A node cannot be operated by somebody without a login on it.** The cost of having no user model.
|
|
If that is ever wanted, the paragraph above says what it costs.
|
|
|
|
## References
|
|
|
|
- [ADR 0032](0032-the-local-account-owns-the-mesh.md) — superseded; same decision, invented category
|
|
- [ADR 0004](0004-a-node-and-how-it-joins.md) — the mesh boundary is the security boundary
|
|
- [ADR 0031](0031-the-control-plane-authenticates-nobody.md) — the control plane authenticates
|
|
nobody
|