Swarm topology discovery -- owner queries peer identities and connections

[careck]

Context

Each peer only knows its direct connections. The workspace owner has no visibility into the full swarm topology — who is connected to whom, or which peers exist beyond their direct neighbors.

Proposal

Allow workspace owners to send an identity discovery request through the swarm via the existing delta sync mechanism. Each peer responds with:

• Their identity information (public key, device ID, display name)
• Their list of direct peers (identity keys / device IDs)

Security model

• Only the owner can send a discovery 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 inside it. Only the owner can decrypt the inner layer.
• This introduces the first request/response messaging pattern in the swarm protocol; existing infrastructure only carries push-based deltas and invites

What this enables

• Network graph visualization — the owner can map the full swarm topology
• Sync diagnostics — identify isolated peers, single points of failure, or unreachable nodes
• Trust context — combined with verification collection (Swarm-wide verification collection and trust graph modeling #152), the owner sees both the trust chains and the network shape they travel through

Implementation note

This is a good first candidate for the request/response messaging primitive — it doesn't depend on #150 (no verification records needed, just existing identity and peer data), making it simpler to build and test. The verification collection feature (#152) can then reuse the same protocol.

Architectural pieces (shared with verification collection)

• New delta payload types — request and response items embedded alongside operations in delta bundles
• Correlation ID so responses can be matched to the originating request
• Owner-only send enforcement (signature check on request)
• Inner-layer encryption of response payload to owner's public key (Ed25519->X25519 conversion or separate key exchange -- TBD), independent of the outer delta transport encryption

Open questions

• Should the peer list include connection metadata (last seen, relay vs direct)?
• How much identity detail to include? (just public key + device ID, or also display name / role?)
• Key derivation: reuse Ed25519->X25519 conversion for encryption, or introduce a separate key exchange?

Dependencies

• Existing identity model (PR feat: identity model foundation (Ed25519 + Argon2id + AES-GCM) #69)

[careck]

Design Note: Storage approach for graph data

No graph database needed — SQLite (already present via SQLCipher) handles this well with adjacency tables and recursive CTEs.

Rationale

• The swarm graph is small and bounded — tens to maybe hundreds of peers, not millions
• Relationships are simple: "peer A is connected to peer B"
• SQLite's WITH RECURSIVE supports arbitrary-depth traversal since 3.8.3
• Adding a graph DB would violate the "krillnotes-core must be reusable" constraint (heavyweight, not embeddable like SQLite)
• Zero new dependencies

Schema sketch

CREATE TABLE swarm_peers (
    peer_id TEXT NOT NULL,
    public_key TEXT NOT NULL,
    device_id TEXT,
    display_name TEXT,
    collected_at TEXT NOT NULL,
    PRIMARY KEY (peer_id)
);

CREATE TABLE swarm_connections (
    peer_id TEXT NOT NULL REFERENCES swarm_peers(peer_id),
    connected_peer_id TEXT NOT NULL,
    PRIMARY KEY (peer_id, connected_peer_id)
);

Example query: find all paths between two peers

WITH RECURSIVE path(current_peer, depth, visited) AS (
    SELECT ?1, 0, ?1
    UNION ALL
    SELECT sc.connected_peer_id, path.depth + 1,
           path.visited || ',' || sc.connected_peer_id
    FROM swarm_connections sc
    JOIN path ON sc.peer_id = path.current_peer
    WHERE path.depth < 20
      AND path.visited NOT LIKE '%' || sc.connected_peer_id || '%'
)
SELECT * FROM path WHERE current_peer = ?2;

Graph visualization would be a frontend concern (force-directed layout in the React UI), reading from these tables via Tauri commands.