Relay Network

The Tunnely infrastructure is not a monoculture of servers owned by a single corporation. It is a distributed, cryptographically secured mesh network of independent relays.

The Node Lifecycle

Every active server in the Tunnely network is running the relay-core headless daemon. This Rust-based application manages three primary obligations:

1. Client Handshakes: Negotiating standard WireGuard tunnels with end-user devices acting as an Entry point.
2. Mesh Communication: Maintaining persistent, encrypted tunnels with other online relay servers in the network.
3. NAT Obfuscation: Serving as an Exit point, translating inbound mesh traffic onto the public internet and returning the responses.

The Server-to-Server Mesh

When a new relay boots up, it pings the central Supabase Edge Functions via the /functions/v1/register-server endpoint. Upon successful authentication (using Service Role keys), it is admitted to the global topology.

The relay immediately pulls down the public keys and IP addresses of all other active nodes in the network. It systematically establishes strict, peer-to-peer WireGuard connections with every one of them. This creates a dense, interconnected web.

          [Relay A] --- [Relay B]
         /         \   /         \
 [Relay C] -------- [Relay D] -------- [Relay E]
         \         /   \         /
          [Relay F] --- [Relay G]

Why a Mesh?

Because all servers are permanently connected to all other servers, the latency required to hop between an Entry Node and an Exit Node is effectively zero overhead beyond the physical fiber distance.

When a user connects through Relay C (the Entry) and requests traffic be exited via Relay G, Relay C does not need to pause and establish a new encrypted tunnel on demand. It simply routes the user's pre-encrypted packet over the existing persistent mesh link to Relay G entirely in kernel space.

Community Operated Nodes (Future Proposal)

Currently, the mesh infrastructure is operated by the Tunnely core team to ensure strict quality-of-service and bandwidth SLAs for our Pro and Enterprise users. However, the exact same `relay-core` codebase that builds our internal network is open source.

Our roadmap includes cryptographic Proof-of-Bandwidth implementations that will allow third-party contributors to operate community nodes, furthering the decentralized nature of the routing topology.