TUNNELCAT
Tunnel Cat is a network of exit and relay nodes around a small, stable backbone. Clients find their way in through signed node lists and a peer-to-peer discovery layer, so no single server has to stay reachable for the network to keep working.
The network is built in layers. The backbone is a small set of servers that hold authority: they register nodes, decide which nodes are trusted, and publish the lists clients rely on. Above it sit control and exit nodes that carry real traffic. Around both, relays and a distributed hash table help clients keep finding a working path even when the backbone is partly unreachable.
Nothing a client trusts is taken on faith. Every list that matters is signed by the backbone's key, and that key is built into the client.
Three roles hold the network together.
Traffic between a client and a control node is wrapped in SNC framing over TLS. The TLS handshake uses a browser-like ClientHello (uTLS), so the connection is indistinguishable from an ordinary browser connection. The SNC channel byte is hidden in the standard TLS Session ID field. The payload is sent as an HTTP-shaped request, split into chunks with randomised sizes and pacing. A probe without a valid key receives a plain 404 and learns nothing about the service.
When a tunnel is lightly loaded, the client sends occasional background HTTPS requests to popular public content endpoints, the way a browser loads page assets. The requests are spaced at random, every 20 to 60 seconds, and are suppressed while the tunnel is busy, so they never compete with real traffic. After ten minutes without any activity the client goes quiet. The aim is that the pattern of connections looks like ordinary browsing rather than one steady stream.
Every client acts as a relay by default. Relays talk to each other directly over UDP, using NAT hole-punching, so a peer behind a restrictive NAT can still reach the network through a neighbour. Requests carry a request ID, a path and a token; responses carry a status code. It is the same request-response model the control API uses, framed for UDP. Relaying can be switched off for the whole network by a signed flag from the directory service. Relays are trusted for what they send, not for who they are: every message is checked the same way, whatever its source.
Nodes find each other through a Kademlia-style distributed hash table, so discovery keeps working when control nodes are unreachable. Node IDs are 256 bits long. The routing table uses XOR distance and k-buckets with k = 8. Relay entries are signed with the publisher's Ed25519 node key and expire unless refreshed.
The DHT speaks its own encrypted UDP protocol with no recognisable Kademlia header, which makes it harder to fingerprint. A node bootstraps from the relay list it gets from a control node and from a local peers file, and saves its routing table periodically. A relay re-announces itself about every 25 seconds, which also keeps its NAT mapping open.
Signed content manifests, lists of files with SHA-256 hashes, spread through the same gossip channel as node lists. A node downloads missing or changed files chunk by chunk, preferring peers that already have a given chunk and falling back to the control relay API when none do. Every chunk is verified against its hash in the signed manifest, whatever its source. Files removed from the manifest are deleted locally.
Clients keep a cached node list and use it when the directory cannot be reached. If the current route stops responding, the client restores it or switches to another available path, without the user having to change settings. WildCat mode reaches the same network through a different carrier: a real video-conference data channel, for networks where the standard transport cannot connect at all.