Inter-Relay Federation and Global App Discovery

[lemon-mint]

1. Vision and Goal

• Current Limitation: A Portal web client is currently restricted to accessing applications registered only on the specific relay server it is connected to.
• Proposed Vision: We propose an architecture to "federate" Portal relays. This would allow a client connected to Relay_A to seamlessly discover and establish a secure, end-to-end encrypted connection to an application hosted on Relay_B, or any other participating relay in the network.
• Expected Benefits:
  • Traffic Distribution: Reduces the operational cost and bandwidth burden on any single relay operator, decentralizing infrastructure load.
  • Enhanced Resilience: The network becomes more resilient to failures or takedowns of individual relays.
  • Censorship Resistance: Users are not dependent on a single entry point, making the network significantly harder to block.

2. Key Architectural Challenges and Considerations

• Network Autonomy and Security:

  • Opt-In Federation: Relays must retain their autonomy. Participation in a federated network must be optional (opt-in).
  • Network Segregation: We must introduce Network IDs to ensure that different Portal networks (e.g., a private corporate network vs. the public network) do not unintentionally mix.
  • Client Integrity: A malicious relay could serve a modified WASM client to intercept or manipulate traffic. A potential mitigation is to establish an "Official Network" that provides a canonical, verifiable client capable of securely accessing all participating relays within that network.

• Global Name Resolution and Discovery:

  • Requirement: Federation requires a reliable, scalable, and secure mechanism for global application name resolution. We need a "Portal DNS" that can map a unique application name to its current Lease ID and its registered relay server(s).
  • Challenges: This system must solve for app name collisions (uniqueness), low-latency lookups, decentralization, and resistance to tampering or spoofing.
  • Potential Solutions: We must investigate the trade-offs of different systems. This could include:
    • ENS (Ethereum Name Service): For a fully decentralized, user-owned naming system.
    • Transparent Logs: A system inspired by Certificate Transparency (CT) logs, which would provide a publicly auditable and verifiable log of all name registrations. (See: https://research.swtch.com/tlog)

• Protocol Design and Interoperability:

  • Relay-Neutral Apps: Applications must be designed to be "relay-neutral," abstracting away the underlying relay infrastructure.
  • Inter-Relay Communication: We need a protocol for relays to share state and application availability (e.g., a Gossip protocol or a DHT).
  • Multi-Relay Transport: The client transport protocol must be upgraded to support multiple relays. This includes capabilities for connection migration or handoff between relays to ensure session persistence, drawing inspiration from protocols like MPTCP or QUIC.

3. Core Principles and Constraints

• The Latency vs. Decentralization Trade-off: We must carefully balance the desire for a fully decentralized network with the practical need for low-latency connections.
• Simplicity is Non-Negotiable: A core strength of Portal is its ease of deployment. Any federation architecture must not sacrifice this. It must remain simple for new users to publish apps and for new operators to launch a relay.
• Incentivizing Participation: As the network scales, we should formalize the idea that running a relay is a tangible contribution, creating a sustainable and clear incentive structure for network growth and health.