Trust and Direct-operated peers
Anyone can run a peer on the P2P network, so discovering one does not establish whether it can be trusted. This chapter explains how the client recognizes Direct-operated peers and verifies that they are authorized to validate providers.
Where trust starts
Each release of the Direct client embeds the current network definition at the time the client was built, cryptographically signed by a quorum from Direct-owned offline private keys. This signed checkpoint is the trust anchor. It gives the client an authenticated starting point for learning which peers are authorized to act as Direct-operated peers.
The network definition includes:
- Approved peers: the public keys identifying Direct-operated peers at the time of release.
- Authorization keys: the current Direct-owned public keys used to verify changes to the network definition. Their private counterparts are held securely offline and used only to sign changes to the network definition.
- Checkpoint: the definition's position in the network history, from which the client checks later changes.
- Signatures: the signatures approving this definition, made with enough of Direct's offline private keys to establish quorum.
The public authorization keys let the client check that Direct signed the trust anchor at startup, while the private keys remain offline.
How Direct operates the network
Direct can approve or remove peers after a client release is published. Each change is recorded as a decision signed by a quorum of Direct's offline authorization keys.
On connecting to the network, a client receives the decisions made since its embedded checkpoint. It verifies each decision in order, checking its signatures against the authorization keys and quorum in the preceding verified network definition before applying the change.
For example, adding a peer means signing a decision approving its public key. Once the client verifies that decision, it can recognize the new identity as a Direct-operated peer when connecting.
Removing a peer follows the same process. After verifying the removal decision, the client no longer treats that public key as authorized to act for Direct. The peer may still be reachable and able to prove its identity, but that proof no longer establishes permission to act as a Direct-operated peer.
The network definition and these decisions live on the P2P network, where Direct-operated peers replicate its signed history through Hypercore. Clients can catch up and receive new decisions through peers while cryptographically verifying that each change was authorized by Direct.
While Direct-operated peers can distribute signed decisions, they cannot sign network changes themselves. Signing requires an offline ceremony in which Direct staff access the private authorization keys held on secure offline hardware and produce the required quorum of signatures. The running peers never hold those keys.
Recognizing a Direct-operated peer
The signed network definition tells the client which public keys to trust as Direct-operated peers. The connection then needs to establish that the remote peer actually holds the matching private key.
The client makes two checks:
- Is the peer's public key approved in Direct's signed network definition? The client checks it against the definition it has cryptographically verified.
- Does the peer hold the corresponding private key? During connection setup, the peer must prove possession of the private key matching its announced public key.
Both checks are needed. Anyone can copy a public key or pass along a signed approval, but neither lets them prove possession of the approved peer's private key.
Trusting independent providers
On a distributed network, consumers may not know whether to trust unfamiliar providers to deliver the services they advertise. Direct uses the trust anchor to provide an authenticated source of information through the Direct-operated peers.
Providers may join the network without explicit approval from Direct. Once they announce their offerings, Direct-operated peers check that the services match what is advertised before making them available to connected consumers. Provider verification continues afterward, keeping consumers informed about service quality as it changes.
Direct can therefore vouch for observed service quality without carrying the service traffic. Requests and responses still travel directly between consumer and provider.