Summary
Peer connections are currently configured statically via the --peer CLI flag or PEAT_SIDECAR_PEERS environment variable. This requires knowing Iroh endpoint IDs at deployment time, which is impractical for dynamic environments where sidecars scale up/down or join the mesh at runtime.
Current State
Peers are configured at startup only (src/main.rs:55-57, 109-117):
#[arg(long, env = "PEAT_SIDECAR_PEERS", value_delimiter = ',')]
peer: Vec<String>,
for peer_id in &args.peer {
if let Err(e) = node.connect_peer(peer_id).await {
warn!(peer = peer_id, "failed to connect to peer: {e}");
}
}
Peer connection is also available via ConnectPeer gRPC RPC (proto/sidecar.proto:25), but this requires an external orchestrator to know endpoint IDs and call the API.
There is no mechanism for automatic peer discovery within a LAN, cluster, or formation.
Proposed Approach
Option A: mDNS/DNS-SD (LAN discovery)
Best for edge scenarios where sidecars are on the same L2 network (e.g., tactical mesh, BLE bridge range).
- Announce service via mDNS:
_peat-sidecar._udp.local with TXT records for app_id and endpoint_id
- Discover peers matching the same
app_id
- Auto-connect on discovery, skip if already connected
- Crate:
mdns-sd or libmdns
Option B: Kubernetes headless service discovery
Best for in-cluster scenarios where sidecars run as Kubernetes pods.
- Create a headless
Service that resolves to all sidecar pod IPs
- Periodically resolve DNS (e.g.,
peat-sidecar-headless.peat-system.svc.cluster.local)
- Exchange endpoint IDs via a lightweight handshake on a known port
- Auto-connect discovered peers
Option C: Gossip-based discovery
Best for multi-cluster or WAN scenarios.
- Each peer maintains a peer table of known endpoint IDs
- On connection, exchange known peer lists
- Attempt connections to newly discovered peers (with backoff)
- Peers propagate via transitive closure
Configuration
New CLI flags:
--discovery-mode <none|mdns|dns|gossip> / PEAT_SIDECAR_DISCOVERY_MODE (default: none)
--discovery-service <dns-name> / PEAT_SIDECAR_DISCOVERY_SERVICE
--discovery-interval <seconds> / PEAT_SIDECAR_DISCOVERY_INTERVAL (default: 30)
Impact
Dynamic discovery is essential for:
- Autoscaling deployments where pod count changes
- Tactical edge networks where nodes appear/disappear
- Reducing deployment complexity (no pre-sharing of endpoint IDs)
- The mobile mesh/tablet bridge scenario described in
docs/DESIGN.md
Files
src/main.rs:55-57 — current static --peer flag
src/node.rs:232-248 — connect_peer() method
chart/peat-sidecar/templates/service.yaml — K8s service (would need headless variant)
Cargo.toml — new dependency for mDNS crate
Summary
Peer connections are currently configured statically via the
--peerCLI flag orPEAT_SIDECAR_PEERSenvironment variable. This requires knowing Iroh endpoint IDs at deployment time, which is impractical for dynamic environments where sidecars scale up/down or join the mesh at runtime.Current State
Peers are configured at startup only (
src/main.rs:55-57, 109-117):Peer connection is also available via
ConnectPeergRPC RPC (proto/sidecar.proto:25), but this requires an external orchestrator to know endpoint IDs and call the API.There is no mechanism for automatic peer discovery within a LAN, cluster, or formation.
Proposed Approach
Option A: mDNS/DNS-SD (LAN discovery)
Best for edge scenarios where sidecars are on the same L2 network (e.g., tactical mesh, BLE bridge range).
_peat-sidecar._udp.localwith TXT records forapp_idandendpoint_idapp_idmdns-sdorlibmdnsOption B: Kubernetes headless service discovery
Best for in-cluster scenarios where sidecars run as Kubernetes pods.
Servicethat resolves to all sidecar pod IPspeat-sidecar-headless.peat-system.svc.cluster.local)Option C: Gossip-based discovery
Best for multi-cluster or WAN scenarios.
Configuration
New CLI flags:
Impact
Dynamic discovery is essential for:
docs/DESIGN.mdFiles
src/main.rs:55-57— current static--peerflagsrc/node.rs:232-248—connect_peer()methodchart/peat-sidecar/templates/service.yaml— K8s service (would need headless variant)Cargo.toml— new dependency for mDNS crate