Federation

Federation lets many hubs cooperate as one cluster, so an agent connected to any hub can discover and drive apps on every hub. A desktop, a laptop, a phone on cellular, and a server appliance all appear as one App Use surface. Federation is off by default — a single-hub deployment behaves exactly as it always has.

The original mental model is "the hub on this PC drives the apps on this PC". But real deployments span more than one device, and you want one place for the agent to talk to. Federation makes "talk to one hub, drive the whole fleet" the default, without the agent caring which physical machine an app actually lives on.

            ┌────────────────────────────────────────────────────────┐
            │                       Cluster                          │
            │                                                        │
   ┌─────┐  │  ┌────────┐         ┌────────┐         ┌────────┐      │
   │ AI  │──┼─▶│ Hub A  │◀───────▶│ Hub B  │◀───────▶│ Hub C  │      │
   │(MCP)│  │  │  PC1   │  LAN   │  PC2   │  RELAY │ phone  │      │
   └─────┘  │  └────────┘  mTLS   └────────┘  WSS   └────────┘      │
            │      ▲                  ▲                  ▲          │
            │      └─ local apps      └─ local apps      └─ local apps
            └────────────────────────────────────────────────────────┘

Two paths, one router

A cluster can stitch hubs together over two transports. The MCP surface the agent talks to (apps.list, app.call) doesn't care which one carries each call — a single router chooses.

  • LAN. Peers on the same network discover each other automatically via mDNS / DNS-SD under _aiappuse._tcp and connect directly hub-to-hub over mutually-authenticated TLS, pinned to a private cluster CA. There is no internet round-trip.
  • Internet relay. Each hub holds one outbound secure WebSocket to a bring-your-own Cloudflare relay. A Noise-IK handshake encrypts every frame end-to-end, so the relay forwards only opaque bytes and cannot read the payload. This lets a phone on cellular join the cluster without inbound NAT holes and without having to trust the relay operator.

Trust model

  • Cluster — the unit of trust. A signed manifest that every member hub holds, identifying the cluster and the membership it covers.
  • Cluster CA — a self-signed root minted when the cluster is first created. The founder hub holds the private key; every other hub carries only the public certificate.
  • Peer certificate — an X.509 leaf signed by the cluster CA. Used both for hub-to-hub mTLS and to sign delegation envelopes.
  • Delegation envelope — a short-lived signed token that carries the originating operator's identity across hubs on every cross-hub call. Signed by the forwarding hub and replay-protected.
  • Sharing policy — set per app, declaring who in the cluster may see and drive it: LocalOnly, Cluster, or specific roles or principals. The default is deny.

Revocation & audit

Trust can be withdrawn quickly. A signed, monotonic revocation list propagates across the cluster in about 60 seconds, and is checked on every handshake and every forwarded call. Every cross-hub call is recorded in a per-hub, HMAC hash-chained federation audit log — any tampering breaks the chain. The operator Console shows a per-peer trust score, folding signature health, audit-head consistency, and quorum checks into a single number.