Why We Chose Relay-As-Floor, Not Fallback-of-Last-Resort

In the world of peer-to-peer (P2P) networking, engineers are trained to view relays as an expensive failure mode.

The conventional wisdom in WebRTC and P2P protocol design goes like this:

1. Attempt direct connection (STUN).
2. If NAT punch fails, perform hole punching (ICE candidate gathering).
3. If symmetric NATs block hole punching, fallback to a TURN relay as an absolute last resort.

When building Qlip, we deliberately rejected this paradigm. We engineered our architecture around Relay-as-Floor.

Here is why this engineering decision yielded a faster, dramatically more reliable experience for real-world cross-platform sync.

---

The Flaws of “Relay as Last Resort” in Modern Networks

In academic networking, direct UDP hole punching is elegant. In real-world enterprise Wi-Fi, CGNAT (Carrier-Grade NAT) on 5G networks, corporate firewalls, and iOS background execution limits, P2P hole punching is fraught with edge-case fragility:

1. High Connection Setup Latency (ICE Gathering Penalty)

Full WebRTC ICE candidate gathering, STUN binding checks, and SDP negotiation take anywhere from 1.5 to 4.5 seconds when network conditions change. For a clipboard application where a user expects to copy on Laptop A and immediately hit Cmd+V on Laptop B, a 3-second negotiation delay feels broken.

2. Symmetric NAT & CGNAT Failure Rates

Modern mobile carriers (AT&T, Verizon, T-Mobile) and corporate enterprise networks frequently employ Symmetric NATs or CGNAT. Under Symmetric NATs, external port mappings change for every destination IP. Traditional STUN hole punching fails over 35% of the time.

3. Mobile OS Background Execution Limits

Both iOS and Android strictly enforce background execution budgets. A background process waking up to receive a clipboard push cannot spend 2,000 milliseconds executing STUN handshake loops before operating system power management suspends the app process.

---

The “Relay-as-Floor” Model

Instead of treating relay routing as a shame-faced fallback, Qlip treats End-to-End Encrypted (E2EE) Relay Routing as our guaranteed performance baseline.

           +-----------------------------------------------+
           |         Qlip Dual-Engine Routing Model        |
           +-----------------------------------------------+
                                   |
                   +---------------+---------------+
                   |                               |
                   v                               v
         [LAN Direct Sockets]            [Relay-As-Floor]
       Local Wi-Fi Subnet Sockets        Persistent Encrypted Relay
         Latency: 8ms - 15ms               Latency: 45ms - 75ms
         Condition: Same Network           Condition: Always Available

Here is how Relay-as-Floor changes the equation:

Always Connected, Instant Delivery

Every Qlip client maintains a persistent, low-overhead TLS socket to the nearest edge relay node. When a copy event occurs while off LAN, the encrypted payload is dispatched over the already-open socket. There is zero handshake setup delay. Transmission latency to the receiving peer is typically 45ms to 75ms.

Zero-Knowledge Guarantee Retained

Because Qlip enforces client-side ChaCha20-Poly1305 encryption prior to payload dispatch, relay servers process only opaque, unreadable byte arrays. The relay server acts purely as a dumb, high-speed routing packet broker. It cannot inspect, store, or log your clipboard contents.

Seamless Upgrade to LAN Direct

While the relay connection guarantees that sync always works in under 80ms, Qlip simultaneously probes local subnets via mDNS in the background. As soon as a local direct socket is verified, Qlip seamlessly upgrades traffic to direct local sockets (8ms - 15ms). If you leave your Wi-Fi router, traffic instantly degrades back to the relay floor — without dropping a single clip.

---

Engineering Takeaways

Building developer tools requires making intentional trade-offs between theoretical purity and user experience:

• Purity vs. Determinism: A system that is 100% P2P but succeeds only 70% of the time creates user frustration. A system that is 100% E2EE and succeeds 99.99% of the time under 80ms creates delight.
• Relays are Cheap, User Frustration is Expensive: By running lightweight, stateless relay nodes across edge regions (US East, US West, EU Central, AP South), global routing latency stays under 80ms worldwide.

By establishing Relay-as-Floor, Qlip provides instant, dependable clipboard synchronization anywhere in the world — regardless of network topology.