Ir al contenido

Trust and admission

Esta página aún no está disponible en tu idioma.

A node does not trust another node because it can reach it. It trusts it because a document it already trusts says who that node is.

The registry is a single signed document that lists every admitted node: its domain, its public signing key and the fingerprint of that key, the protocol versions it speaks, what it is able to do, and whether it is active or revoked.

Every node holds one key — the registry’s root public key. That key is the only thing a node trusts outright. Everything else follows from it: the node checks the registry document against that key, then checks each incoming message against the signing key the registry publishes for the sender.

A node with no root key configured does not guess. It refuses to resolve any peer at all, and says so.

The document is signed, so where it is served does not matter. It carries an issue date and an expiry, and it is re-issued regularly so the expiry stays ahead.

Admission is a review, not a registration.

When a node is installed it produces an admission payload. That payload holds public material only: the node’s domain, its federation signing public key and fingerprint, its client-certificate fingerprint, the protocol versions and the capabilities it declares. There is no private key material in it and none is asked for.

The operator submits the payload. The node signs the submission with its own key, which proves it holds the private half of the key it is claiming. That is all a signature can prove — it says nothing about who owns the domain. So the submission lands in a queue for a person to look at, and the operator confirms the key fingerprint through some other channel. A human approves it.

Once approved and the registry is re-published, the node federates. Submitting again before approval refreshes the pending entry rather than creating a second one.

Nothing about the payload grants trust on its own.

A node is removed by marking its registry entry revoked and re-publishing. Revoked entries stay in the document for about a month rather than vanishing, so it stays visible that the node was once there and is no longer.

From the moment other nodes fetch the re-published document, messages from the revoked node are refused like any other unknown sender.

Before they exchange anything else, two nodes shake hands. Each sends the list of things it can do; the answer is the overlap. That overlap is what the pair can use for the rest of the exchange.

This matters because nodes are not always at the same version. A node that receives a message it recognises but has not implemented refuses it cleanly, and — importantly — does not mark it as delivered, so the sender can try again once both sides have the feature.

Admission is mesh-wide. An operator can also refuse an individual node locally, without waiting for anything central: the admin app lists every server the node has dealt with and lets you cut one off. That decision takes effect on your node only.

Doing so needs a permission your first administrator already holds.