Swarm-wide verification collection and trust graph modeling

[careck]

Context

After #150 lands, each peer stores local verified_by records — "which of my direct peers vouched for this op." But each node only sees one hop of the trust chain. The workspace owner has no way to see the full verification path from author through the chain of vouches.

Proposal

Allow workspace owners to send a verification collection request through the swarm via the existing delta sync mechanism. Each peer responds with their local verified_by records. The owner aggregates these into a trust graph per operation showing the full vouching chain.

Security model

• Only the owner can send a collection request (enforced by signature verification — peers reject requests not signed by the owner)
• Requests travel inside deltas — encrypted between each pair of peers like any other delta payload. Each peer can read the request (to act on it and forward it), but it is never plaintext on the wire.
• Responses are double-encrypted — the response content is encrypted to the owner's public key (inner layer), then wrapped in normal delta transport encryption (outer layer). Intermediate peers can decrypt the delta envelope but cannot read the response payload. Only the owner can decrypt the inner layer.
• Uses the same request/response messaging primitive introduced by swarm topology discovery (Swarm topology discovery -- owner queries peer identities and connections #151)

What this enables

• Trust graph construction — the owner combines verification records from multiple peers to build a directed graph: author -> first-hop verifier -> second-hop -> ... extending trust reasoning beyond what any single node knows locally
• Verification auditing — the owner can see which operations have strong vouching chains vs. weakly verified ops
• Anomaly detection — gaps or inconsistencies in the vouching chain may indicate tampered or unverified operations

Open questions

• Should collection be scoped (e.g., "verification records for ops since timestamp X") or always full?
• How to handle offline peers? Store-and-forward via relay, or retry on next sync?
• Should the assembled trust graph be persisted or computed on-demand from collected records?

Dependencies

• Per-operation signature verification and transitive vouching #150 (per-operation verification and transitive vouching)
• Swarm topology discovery -- owner queries peer identities and connections #151 (swarm topology discovery — introduces the request/response messaging primitive)

[careck]

Design Note: Storage approach for trust graph data

Same approach as topology (#151) — SQLite adjacency table with recursive CTEs. No graph database needed.

Schema sketch

CREATE TABLE collected_verifications (
    op_id TEXT NOT NULL,
    peer_id TEXT NOT NULL,
    verified_by_peer_id TEXT NOT NULL,
    collected_at TEXT NOT NULL,
    PRIMARY KEY (op_id, peer_id)
);

Example query: walk the full vouching chain for an operation

WITH RECURSIVE chain(op_id, verifier, depth) AS (
    SELECT op_id, verified_by_peer_id, 0
    FROM collected_verifications
    WHERE op_id = ?1 AND peer_id = ?2  -- start from a known peer
    UNION ALL
    SELECT cv.op_id, cv.verified_by_peer_id, chain.depth + 1
    FROM collected_verifications cv
    JOIN chain ON cv.peer_id = chain.verifier AND cv.op_id = chain.op_id
    WHERE chain.depth < 20  -- safety bound
)
SELECT * FROM chain;

Notes

• Shares the same SQLCipher database — no new dependencies
• Could optionally materialize a summary table on each collection for faster reads
• Trust graph visualization is a frontend concern, same as topology (Swarm topology discovery -- owner queries peer identities and connections #151)
• The swarm_peers table from Swarm topology discovery -- owner queries peer identities and connections #151 is referenced here too — both features share the peer identity data