peeza — how it works

The path a file takes

A light native app drives a background engine that runs every transfer. The engine connects through a small relay, then sends 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 does signaling: it helps the two sides find each other. If a direct path is impossible, it forwards bytes it cannot read. It never stores a file.

01Why the relay can't read your files

Every transfer is encrypted. The key travels in the link, or sealed to the receiving device. The relay doesn't get it, with one exception, at your request. You trust our servers in two places: the web page that decrypts in a browser and the first key for a new device.

The key lives in the link, not our database

Your machine makes a key for each share and puts it in the link's fragment: g.peeza.app/7XK4M2QD#k=…. Browsers never send the part after # to a server. It stays on the two devices, which derive the AES-256-GCM transfer keys from it. The relay sees the room, not the key, unless you ask another of your devices for the link (§10.1). In a browser, our server delivers the page that reads the key (§10.2).

Encrypt-then-forward. Chunks are sealed on the sender and opened on the receiver. In between, our relay included, there is only ciphertext.
Directed sends stay sealed. Each of your machines has an X25519 keypair. Keys travel in sealed envelopes the relay can't open. A new device's first public key does come from the relay. Pairing in person removes that trust (§10.3).
Local pairing. The first time two devices connect over the network, both confirm the same 6-digit code. Then the peer is pinned and trusted. Devices paired through your account skip this.

The relay keeps metadata, never file contents: your account, your devices and their public keys, one-time share links that expire after 48 hours, your teams with the names and sizes of their files, and a connected device's transfer list with file names, for your dashboard. IP addresses stay in memory: to connect devices, to rate-limit, and for up to 15 minutes when you connect a new device. Never written to disk, never logged. Details: our privacy policy and what the relay sees.

02Any size, constant memory

peeza streams. It never loads a whole file, 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.
A folder is zipped to a point-in-time snapshot. Editing the source mid-transfer can't corrupt what's in flight.
Downloads are written to a partial file on disk, never assembled whole in RAM.

04Staying direct

The relay is a fallback, not the default. Direct is faster and, for you, unlimited.

STUN redundancy. Several servers find each side's public address, for better odds of a clean hole-punch.
At startup, peeza tries to pin a router port with UPnP / NAT-PMP and offers it as an extra candidate. Best-effort. You can switch it off.
On the same network? Switch on Nearby. peeza finds other Peezas on your Wi-Fi and transfers directly. No relay, no internet, no login.

05One send, a whole team

A team is a standing group of people and their machines. Drop a file on the team and every member gets it, with the same encryption.

Fan-out, sealed per recipient. The transfer key is sealed to each member machine's keypair. The relay routes envelopes it can't open. Each delivery waits for its recipient to accept it.
Swarm delivery. Machines that hold pieces of the file pass them on, torrent-style. The sender's uplink stops being the bottleneck.
A team holds its files. Join later and you still see earlier shares. The catalogue belongs to the team, not a link.

06Little to hold, by design

peeza never stores your files and cannot read them. It does process your account, your devices, your teams with the names of files shared there, and transfer metadata, on a relay in the United States. That is personal data, and privacy law applies. The full list is in the privacy policy.

No stored copy of your files. Files never land on our servers. Nothing to breach, leak, or hand over.
Privacy by design and data minimization, core GDPR principles, shape the architecture: end-to-end encryption on every path, file contents we cannot read, IP addresses only in memory. That does not make peeza exempt. The privacy policy lists the metadata we process and how long we keep it.
Files don't sit in a foreign data center. They go from one machine to the other. Account data and transfer metadata do cross borders: the relay runs in the United States (where data is handled).
Nothing in your files to train on. We don't store your files and can't read them. AI-training clauses and new retention limits have nothing of yours to reach.

A file, straight from one machine to another.