What connecting to the mesh is, and what a node presents

Two things this record never said, both asked directly.

Connecting to the mesh is one outbound AMQP connection from the node to the
broker, held open. There is no second connection and nothing is ever dialled at
a node. Being in the mesh means that connection is up.

Two different things ride on it and conflating them is what made this murky. An
AMQP account, which the mesh issues per node at enrolment, answers whether the
connection is accepted at all -- per node rather than shared, because a shared
one lets any node consume another's queue, which is the shared-credential fault
this record exists to remove reappearing at the transport.

The node's own keypair answers which node is speaking, on every message. It is
not made redundant by the account: with only an account the control plane knows
who is speaking because the broker says so, and that is the same transitive
authority this record already refuses in the other direction. A compromised
broker could attribute reports to whichever node it liked.

So a node holds two things after enrolment -- a credential the mesh issued for
reaching the broker, and a key it generated that the mesh only sees the public
half of. Both are its own, neither reaches anything else.

02-DECISIONS/0004-a-node-and-how-it-joins.md

@@ -143,6 +143,39 @@ mesh's copy is a public key, so a copy of the mesh's database grants nothing. *C
 is compromise of that node* becomes true rather than aspirational, because the only secret on a
 machine is the one that identifies it.
 
+### What "connecting to the mesh" is, concretely
+
+*Written 2026-08-29, because it was asked and this record had never said it.*
+
+**One outbound AMQP connection from the node to the broker, held open.** That is all of it. There
+is no second connection and nothing is ever dialled *at* a node. Being in the mesh, operationally,
+means that connection is up; being disconnected means it is not
+([`09-the-node-lifecycle.md`](../03-DESIGN/01-to-be/09-the-node-lifecycle.md)).
+
+**Two different things ride on it, and conflating them is what made this confusing:**
+
+| | what it answers | who issues it |
+|---|---|---|
+| **an AMQP account** | may this connection be accepted at all | **the mesh, at enrolment** |
+| **the node's keypair** | which node is speaking, on every message | **the node**, above |
+
+**The account is the mesh's to issue**, and per node. The broker has to authenticate somebody
+before a connection exists, and a shared account would let any node consume another's queue —
+which is the shared-credential fault this record exists to remove, reappearing at the transport.
+So enrolment creates that node's account and hands it over, and it is rotatable without touching
+the node's identity.
+
+**The keypair is not made redundant by it.** With only an account, the control plane would know
+which node is speaking *because the broker says so* — and that is the same transitive authority
+this record refuses in the other direction. A compromised broker could then attribute reports to
+whichever node it liked, and the control plane would act on them. Signing is what removes the
+broker from the question in both directions.
+
+**So a node holds two things after enrolment**: a credential the mesh issued for reaching the
+broker, and a key it generated itself that the mesh only ever sees the public half of. Both are
+its own, neither reaches anything else, and *compromise of a node is compromise of that node*
+still holds.
+
 ### Its own key, not the machine's SSH host key
 
 Reusing the host key is the obvious economy and it is refused, for reasons that are operational