Trust Graph

Trust between two state machines is encoded as edges in ssl_trust_relations:

CREATE TABLE ssl_trust_relations (
  truster_machine_id   uuid,
  trusted_machine_id   uuid,
  granted_at_zeqond    bigint,
  revoked_at_zeqond    bigint NULL,
  trust_level          'basic' | 'peer' | 'federated',
  signature            char(64)
);

Resolution

resolveTrust({ from, to, queryZeqond }) performs a BFS from from outward, capped at SSL_MAX_TRUST_HOPS = 4. The walk terminates as soon as to is hit along any path that satisfies the level rules.

Level rules

Level	Hops allowed	Transitivity
basic	1 only	NEVER transitive — recorded but does not propagate
peer	1 only	Final-hop edge; does not chain
federated	Up to MAX_TRUST_HOPS = 4	Chain through federated→federated→target

Mixing levels along a path: the weakest edge defines the effective level of the resolved relationship.

Revocation

revoked_at_zeqond is set when a trust edge is revoked. Revoked edges are filtered out of the BFS by queryZeqond comparison:

WHERE revoked_at_zeqond IS NULL OR revoked_at_zeqond > <queryZeqond>

So you can ask "did A trust B at Zeqond N?" historically — the row stays for audit even after revocation.

Self-trust

Rejected at the schema level (CHECK chk_no_self_trust). The resolver returns { trusted: true, hops: 0 } for from === to as a degenerate case.

Why a graph, not a flat list?

Federation. If machine A trusts machine B, and B trusts a wider set of machines, A may want to honour B's choices without re-asserting every edge. The federated level expresses that. Capping at 4 hops keeps the BFS bounded — any business relationship requiring deeper chains should declare the bilateral edge explicitly.

Visualisation (Phase 2.2)

The /apps/zeq-ssl/ manager renders the outgoing-edge subgraph for a machine. A full D3 force-layout of the network ships in Phase 2.2 once we have telemetry on realistic graph sizes.