feat(discovery): add IVNP-backed overlay discovery

[gosunuts]

Problem

Portal currently owns both relay semantics and the transport used to discover relays. The existing overlay path uses WireGuard peers plus Portal-specific synchronization, while HTTPS bootstrap/announce remains the fallback.

As discovery grows, Portal risks reimplementing more P2P routing and peer-discovery machinery that IVNP/I2P already provides.

Proposal

Add an optional IVNP-backed discovery transport behind the existing OverlayRuntime boundary.

type OverlayRuntime interface {
    DiscoverRelay(context.Context, types.RelayDescriptor) (types.DiscoveryResponse, error)
    Sync([]types.RelayDescriptor) error
}

The IVNP implementation should use I2P only to reach another Portal relay and exchange the existing Portal DiscoveryResponse. Portal must continue to own relay admission, descriptor signatures, expiry/rollback checks, health state, and MOLS ranking.

Conceptually:

RelayDescriptor
      ↓
IVNP / I2P StreamNetwork
      ↓
Portal discovery exchange
      ↓
DiscoveryResponse
      ↓
RelaySet admission
      ↓
MOLS ranking

Scope

• Add an I2P destination/address field to relay discovery metadata if needed.
• Implement an IVNP-backed OverlayRuntime using IVNP StreamNetwork / DialI2P.
• Keep RelayDescriptor and DiscoveryResponse as Portal-owned contracts.
• Keep HTTPS discovery as bootstrap/recovery while the IVNP path is optional.
• Do not move Portal descriptors into I2P RouterInfo/LeaseSet fields or use NetDB as an arbitrary Portal KV store.
• Do not replace the tenant data plane or multi-hop transport in this issue.
• Do not treat I2P identity as Portal relay admission or Sybil resistance.

Important semantics

Discovery latency over I2P is not equivalent to clearnet relay ingress latency. The IVNP path should therefore not feed I2P round-trip time into the existing relay-performance score used by MOLS. Discovery transport latency and relay ingress/health measurements should stay separate.

The current 30-second polling model should also not be copied mechanically onto I2P. Prefer cached descriptors with refresh driven by expiry/topology changes or a substantially slower IVNP discovery cadence.

Why

This keeps the responsibility split clean:

IVNP / I2P:
  peer discovery
  routing
  overlay reachability
  NAT-independent connectivity

Portal:
  relay identity and descriptor semantics
  admission and rollback protection
  health checks
  selection and MOLS ranking
  public ingress/data plane

This should let Portal reuse a mature anonymous overlay substrate without turning the Portal discovery layer itself into a second general-purpose P2P routing system.

Related project: https://github.com/gosuda/IVNP

[gosunuts]

I think the scope here should be reconsidered based on the newer multi-hop/NAT discussion in #358.

The current issue deliberately limits IVNP to a discovery transport and keeps Portal's WireGuard multi-hop/data plane unchanged. After looking at the responsibility boundaries more closely, that may be too conservative.

IVNP already provides the properties Portal otherwise has to keep rebuilding around the relay mesh:

• peer discovery
• overlay reachability independent of public inbound endpoints
• NAT/CGNAT-friendly participation
• multi-hop routing/tunnel construction

Portal's custom relay overlay currently owns discovery, WireGuard peer synchronization, direct-hop reachability assumptions, hop-route installation, and middle-hop forwarding. Keeping all of that while adding IVNP only for discovery risks ending up with two overlapping overlay models.

A cleaner target architecture would be:

Public edge
Browser -> Portal relay
ordinary HTTPS / SNI

Application backhaul
Portal relay <-> tunnel client
direct reverse stream by default

Relay overlay
Portal relay <-> Portal relay
IVNP
- discovery
- NAT-independent reachability
- multi-hop
- volunteer middle transit

WireGuard can remain as an optional/direct fast path where both relays have usable public endpoints, but it should not necessarily remain the owner of Portal's multi-hop semantics.

The important distinction is that I would not move the normal relay-to-tunnel-client backhaul to IVNP by default. The tunnel client already connects outbound to a public relay, so NAT is not a problem there, and routing the primary application traffic through I2P would be a performance regression. IVNP could still be an optional privacy/censorship-resistant backhaul later.

For relay-to-relay connectivity, however, multi-hop is mainly a privacy/decentralization feature, so IVNP is a natural owner of that complexity.

I suggest expanding #324 from "IVNP-backed discovery transport" toward "optional IVNP relay overlay" and treating #358's NATed middle-only worker as one of its key acceptance scenarios. If this direction works, Portal should be able to delete or substantially shrink custom discovery/multi-hop/WireGuard-routing code instead of adding another transit-worker subsystem.

[gosunuts]

Updated implementation plan based on the latest direction:

1. Introduce IVNP as the relay-to-relay overlay first.

   • Give each public Portal relay an IVNP destination.
   • Add the minimal ability for relay A to open an authenticated stream to relay B through IVNP.
   • Keep the existing public HTTPS ingress and tunnel-client reverse backhaul unchanged.

2. Move relay-to-relay transport onto IVNP.

   • Replace the current WireGuard/yamux hop stream path with an IVNP stream path.
   • The important boundary should stay narrow: "open an authenticated stream to another Portal relay" rather than introducing a broad generic networking abstraction.
   • Keep the existing direct path during migration until the IVNP path is proven end-to-end.

3. Move multi-hop responsibility out of Portal.

   • Portal should stop constructing explicit A -> B -> C relay paths.
   • IVNP/I2P should own the internal multi-hop path, NAT-independent reachability, and intermediate router selection.
   • Once this is authoritative, remove Portal-specific HopRoute chaining, ForwardRelay, ForwardToken, /sdk/hop, OpenHopStream, and SDK multi-hop orchestration.

4. Retire the WireGuard relay overlay.

   • After IVNP relay-to-relay traffic is stable, remove WireGuard peer sync, overlay IPv4 derivation, WireGuard endpoint metadata, and the relay overlay stack.
   • WireGuard should not remain as a parallel relay-mesh implementation unless there is a concrete independent use case; maintaining both would duplicate path selection, health, retry, and reachability state.

5. Keep Portal relay discovery semantics, but move network discovery/reachability down.

   • Portal still needs a public relay catalog: relay identity, public HTTPS ingress URL, capabilities, health/load, admission, expiry, rollback protection, and relay selection.
   • IVNP should own peer discovery, overlay routing, NAT reachability, and relay-to-relay connectivity.
   • In other words: IVNP discovers/reaches peers; Portal decides which public relay is acceptable/useful.

6. Reduce MOLS to public relay selection only.

   • Keep MOLS for deterministic distribution of tunnel clients/listeners across eligible public relays and for load/saturation-aware ranking.
   • Remove MultiHopDepth, buildMOLSPaths, path-diversity construction, and multi-hop-specific selection state.
   • The desired MOLS contract becomes roughly:

   RankRelayPool(eligibleRelays, localIdentity, epoch) []string

   It should return an ordered public-relay priority list and nothing about the internal overlay path.

7. Re-evaluate MOLS after the responsibility reduction.

   • Once MOLS is only a relay selector, compare the remaining value against a simpler HRW/rendezvous-hashing policy again.
   • Do not preserve MOLS complexity merely because the current implementation also handles multi-hop today.

8. Absorb feat(relay): support NATed outbound-only transit workers #358 as an IVNP use case rather than a new Portal subsystem.

   • NAT/CGNAT volunteer middle capacity should come from the IVNP overlay rather than TransitDescriptor, coordinator-owned worker sessions, brokered route installation, or a second relay role in Portal.
   • Portal should not need to know which IVNP routers are public, NATed, volunteer, or intermediate.

Target architecture:

Browser / ordinary client
        |
     HTTPS/SNI
        v
Public Portal Relay
        |
        | IVNP overlay
        | - peer discovery
        | - NAT-independent reachability
        | - multi-hop routing
        v
Other Portal Relay
        |
        | existing direct reverse backhaul
        v
Tunnel client

The migration should be deletion-oriented: establish the IVNP relay path first, make it authoritative, then remove the custom WireGuard/multi-hop machinery rather than permanently supporting two overlay systems.