peeza — how it works

The path a file takes

A light native app drives a background engine that owns every transfer. The engine negotiates a connection to the other side through a small relay, then moves the file directly when it can.

┌─────────────┐   localhost    ┌─────────────┐     signaling      ┌──────────────┐
│ Native app  │ ─────────────▶ │   engine    │ ◀────────────────▶ │ relay server │
│  (desktop)  │   token auth   │ (background)│  connection setup  │   (cloud)    │
└─────────────┘                └─────────────┘                    └──────────────┘
                                      │  ╔══════ direct peer-to-peer ══════╗
                                      └─ ║   or blind relay when blocked   ║ ─▶ other machine
                                         ╚═════════════════════════════════╝

The relay's job is signaling — helping the two sides find each other — and, only when a direct path is impossible, forwarding bytes it cannot read. It never stores a file.

01Why the relay can't read your files

This is the part that matters most. Every transfer is encrypted with a key the server never receives.

The key lives in the link, not our database

When you create a share, your machine generates a per-share AES-256-GCM key and puts it in the link's fragment: peeza.app/r/AbC…#k=…. Browsers never send the part after # to a server — it stays on the two devices. The relay sees the room, not the key.

Encrypt-then-forward. Chunks are sealed on the sender and opened on the receiver. Anything in between — including our relay — handles ciphertext only.
Directed sends stay blind too. Sending to your own devices uses per-machine X25519 keypairs and sealed-key envelopes, so the relay can route without ever holding a key.
AirDrop-style pairing. A first local connection is confirmed with a matching 6-digit code, then the peer is pinned so it's trusted next time.

02Any size, constant memory

peeza streams. It never loads a whole file to send it, so a 400 GB folder uses about as much memory as a 4 MB one.

Files are read off disk in small chunks, encrypted, and sent one at a time — memory stays flat at any size.
A folder is zipped to a point-in-time snapshot, so editing the source mid-transfer can't corrupt what's in flight.
Downloads are written to a partial file on disk, so a receiver never assembles the whole thing in RAM either.

03Resumable by default

Transfers are state on disk, not a live process you have to babysit.

peeza keeps transfer state and partial downloads on disk. Close the window, quit the app, reboot the machine — when both sides are back, the transfer resumes from the last byte written, not from zero.

04Staying direct

The relay is a fallback, not the default. peeza works to keep transfers on a direct path, because direct is faster — and, for you, unlimited.

STUN redundancy discovers each side's public address through several servers, improving the odds of a clean hole-punch.
At startup, peeza tries to pin a port on your router with UPnP / NAT-PMP and advertises it as an extra candidate — best-effort, and you can switch it off.
On the same network? peeza finds nearby Peezas automatically — AirDrop-style — and transfers directly. No relay, no internet, no login.