33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# ECP-0008: iroh discovery + transport design
|
||
|
||
Status: Draft
|
||
|
||
## Problem
|
||
|
||
We need a discovery and transport layer that can survive hostile networks, reduce central points of failure, and support stream swarms across independently hosted relays.
|
||
|
||
## Decision
|
||
|
||
Adopt iroh as the mesh substrate with the following design:
|
||
|
||
- **Dial by public key**: every node has an iroh endpoint identity; connections are established by endpoint id with automatic hole punching and relay fallback.
|
||
- **MoQ over iroh**: run MoQ sessions over iroh QUIC connections using a dedicated ALPN (e.g. `every.channel/moq/0`).
|
||
- **Discovery via gossip**: use iroh-gossip to disseminate stream catalogs and track announcements, keyed by `StreamId`.
|
||
- **Transport flexibility**: support iroh custom transports (e.g. Tor) for nodes that need anonymity or censorship resistance.
|
||
- **Multipath first**: leverage iroh’s multipath QUIC capabilities to increase resilience and adapt to changing network conditions.
|
||
|
||
## Consequences
|
||
|
||
- Nodes can join the swarm with minimal configuration and no centralized registry.
|
||
- The mesh can degrade gracefully under takedown pressure by routing through relays or Tor.
|
||
|
||
## Alternatives considered
|
||
|
||
- Centralized rendezvous servers: rejected due to fragility and governance risk.
|
||
- Manual peer lists: rejected due to onboarding friction.
|
||
|
||
## Rollout / teardown
|
||
|
||
- Add an iroh transport crate that exposes a `connect` API for MoQ sessions.
|
||
- Implement gossip-based stream catalog synchronization.
|
||
- Add optional Tor transport profile for high-risk regions.
|