Skip to content

What stays central

Running your own node moves your data to your machine. It does not move everything, and the exceptions are worth knowing before you decide.

The mesh has exactly one trust anchor: the key that signs the registry document. Its private half stays with whoever operates the registry — for the public mesh, trusted.codes Inc. — and never leaves that custody.

That is what makes admission meaningful. If every node could sign the list, being on the list would say nothing.

Admission itself is a human decision made centrally. So is revocation. See Trust and admission.

Billing is central and has no operator setting. Your node has no payment configuration to fill in and never handles a card.

There is one Trusted Codes mobile app in the stores, and one set of credentials that Apple and Google accept for it. Those credentials are not distributed to operators.

So push for your users goes out centrally, on your node’s behalf. Your node holds the device tokens; it hands them over for delivery, with no content attached. What that carries — and does not carry — is set out in What crosses between servers.

If it fails, nothing is lost. The app catches up when it is next opened.

A node that runs under an Operating Grant holds a signed statement of what it is entitled to. The node renews it on a schedule by signing an attestation and asking central for a fresh one.

Silence expires the grant. If the node stops asking, or central declines, the grant it holds simply runs out rather than continuing indefinitely. A renewal attempt that cannot reach central does nothing and is retried; it does not break the node.

A node that does not run under a grant is unaffected by any of this.

A node that cannot create accounts — because it accepts new people by invitation only, or not at all — cannot onboard somebody who has no account anywhere. If the operator has enabled it, the node offers such an invitation to trusted.codes, the person registers there, and the connection is completed on the node afterwards.

This is the only routine case where a node hands over an email address, and it is off by default.

Your database. Your users. Your sign-in. Your domain and its certificate. Your email transport, which carries all of your node’s mail, both sign-in and application.

Any keys you supply for the optional services — geolocation and fraud scoring, the AI assistant, the embedded dashboards — are yours, for your deployment. They are not visible outside your node, and leaving them out simply turns that feature off.

Which portal surfaces your node serves, and whether they are running, is yours as well. The admin app can tell you the command; it cannot start or stop anything on your host itself.