import type { Broker } from "./broker.js";
import { BrokerRemote } from "./broker_remote.js";
import { PiForwardClient } from "../transport/pi_forward_client.js";
import type { RelayClient } from "../transport/relay_client.js";
import type { Ed25519Keypair } from "../pairing/crypto.js";
/**
 * Cross-PC mesh bridge composition — the single shared point for "turn a
 * leader Broker + relay into a cross-PC router".
 *
 * Both consumers call this so the wiring lives in one place:
 *   - The Pi extension (`_ensureBrokerRemote`) injects its relay — the SAME
 *     RelayClient it also uses for app↔Pi pairing.
 *   - The MCP `MeshNode` creates its own RelayClient and passes it in.
 *
 * The function does NOT own the relay's lifecycle (the caller created it and
 * tears it down). It only attaches the PiForwardClient + BrokerRemote on top.
 *
 * Sibling discovery is best-effort: on any failure we attach a BrokerRemote
 * with an empty sibling set, and remote `peers_update` pushes fill the cache
 * in later. Discovery warnings are routed to the silent `log` so they never
 * bleed into a Pi TUI chat panel.
 */
export interface AttachBridgeOptions {
    /** The leader's local Broker (from SessionPeer.localBroker()). */
    broker: Broker;
    /** Live relay connection. Caller owns its lifecycle. */
    relay: RelayClient;
    /** Relay URL in http(s):// form — for MeshClient sibling discovery. */
    relayUrl: string;
    /** This host's Ed25519 identity (machine Pi-key). */
    keypair: Ed25519Keypair;
    /** Diagnostic logger. Defaults to a no-op (avoids TUI leaks). */
    log?: (msg: string) => void;
}
export interface CrossPcBridge {
    brokerRemote: BrokerRemote;
    piForward: PiForwardClient;
}
export declare function attachCrossPcBridge(opts: AttachBridgeOptions): Promise<CrossPcBridge>;