quix.sh
11/15/2025

P2P Architecture at Quix.sh

A deep dive into how Quix.sh connects browsers directly with reliability and speed.

Why peer‑to‑peer?

Traditional file sharing uploads your data to a server first - that’s slower, more expensive, and expands the surface area for privacy issues. Who has access to this data? Where is it stored?

Quix.sh redefines file sharing between devices with a secure, fast, and easy peer‑to‑peer approach.

Goals

  • Minimal latency and hops
  • End‑to‑end privacy
  • No long‑term storage

The connection lifecycle

Establishing a P2P session involves a short handshake supported by a lightweight signaling service. Quix.sh uses this signaling layer solely to exchange SDP offers/answers and ICE candidates.

1. Session bootstrapping

  1. The sender opens Quix.sh and generates a 6‑digit code.
  2. The receiver enters that code.
  3. The signaling layer temporarily pairs both clients for setup.

2. NAT traversal with STUN/TURN

WebRTC gathers ICE candidates and evaluates possible routes:

  • STUN discovers public IP/port mappings.
  • WebSocket fallback is available for verified users to maintain connectivity in restricted networks.

Data channels and flow control

Files are sent over WebRTC data channels with built‑in backpressure handling.
Browser memory remains safe through chunked reads and adaptive pacing.

Integrity and verification

Before sending, every file is hashed client‑side:

import { sha256 } from '@/lib/hash';
const digest = await sha256(file);
// Sent in header; verified by receiver after download

Resilience strategies

  • Automatic reconnection during transient network changes
  • Graceful cancellation and resume windows
  • Strict timeouts on idle sessions

When do we choose WebSockets

While direct WebRTC connections are preferred, they may fail in heavily restricted networks. For these cases, verified users can switch to a WebSocket connection to preserve reliability and transfer speed, even under strict firewall policies.

Security posture

WebRTC DTLS/SRTP encrypts all data in transit. On top of this, Quix.sh applies additional application‑level integrity checks and avoids server‑side storage altogether.

What we never do

  • Store your files on the server
  • Inspect or analyze file contents
  • Retain logs containing sensitive metadata

Looking ahead

We’re exploring:

  • Multi‑recipient sessions
  • Bandwidth‑aware chunking strategies
  • Better diagnostics for constrained network environments

Quix.sh will continue to evolve around one principle: private‑by‑default file transfers that are fast, reliable, and effortless for everyone.