Last updated: 2026-07-09
"Peer-to-peer" gets used loosely, so here's what it actually means for a file transfer: your file goes straight from one device to the other, not up to a company's server and back down. No stop in the middle where a copy could sit.
That sounds simple, but the internet isn't built for two random devices to just find each other and talk directly — most connections are hidden behind routers and firewalls that were never designed to be reached from outside. This page explains, in plain terms, how a direct connection actually gets made, when it can't be made, and what that means for your privacy and speed. Relayium is used as the concrete example throughout, since it's a working implementation of exactly this.
Most "send a file" tools work by uploading: your file goes from your device up to the company's server, gets stored there, and the other person downloads it back down. That's two hops, and for a while, a full copy of your file sits on someone else's storage — even if it's deleted later.
Peer-to-peer transfer skips that stop. Once a connection is open between your device and the other person's, the file's bytes flow directly across that one hop and nowhere else. There's no server-side copy to store, to secure, or to eventually delete, because it was never uploaded in the first place.
Here's the part that isn't obvious: your device almost certainly doesn't know its own address as seen from the outside internet — it sits behind a home router or a mobile carrier's network address translation (NAT), which hides it behind a shared public IP and reassigns ports on the fly. The other device is in the same situation. Neither one can just "dial" the other directly without first figuring out what address would actually reach it.
That's what STUN (Session Traversal Utilities for NAT) is for. Each device briefly asks a small, lightweight STUN server one question: "what address and port do you see me coming from?" The answer tells it its own public-facing address — not the file, not any content, just enough network information to describe a path back to it. Both devices exchange this information (via a signaling step that only carries connection-setup details, never file bytes) and then try to open a direct path to each other's address. In a large share of real-world cases — especially two devices on the same Wi-Fi, or NATs that behave predictably — this works, and a fully direct connection opens.
Sometimes STUN isn't enough. Some NATs — especially on stricter corporate networks or certain mobile carriers — are unpredictable enough that no direct path can be discovered from outside information alone. If both devices are behind that kind of NAT, a genuinely direct connection just isn't possible; something has to relay the traffic in between.
That's what TURN (Traversal Using Relays around NAT) is: a fallback relay server that both devices connect to when a direct path fails. It's not a workaround or a compromise on privacy so much as a necessity of how some networks are built — but it's worth being precise about what it does and doesn't see. In Relayium, the file is already encrypted end-to-end before it reaches the relay, so the relay only ever forwards ciphertext — sealed data it has no key to open. It moves bytes; it cannot read them.
The privacy case is straightforward: when the file's bytes only ever cross one hop, straight between two devices, there's no server-side storage step where a copy could sit, get logged, or get accessed by anyone else — because it was never put there. That's a structurally different guarantee than "we promise to delete it eventually."
The speed case follows the same logic. An upload-then-download transfer has to cross the network twice — once up, once down — and often waits on the sending side to fully finish before the receiving side can start. A direct connection crosses the network once, and data can stream continuously between the two devices as fast as the slower connection allows, without a server in the middle limiting throughput or adding its own latency.
Open relayium.com on two devices on the same network and they typically find each other automatically — no account, no code, nothing to install; that's the LAN case where STUN often isn't even needed. Sending across the internet to someone on a different network uses a pairing code: the sender signs in, generates a code (or shares a link, with an optional QR code to scan), and once the other person joins, the same STUN-then-TURN-if-needed process runs to open a direct or relayed connection — the receiver never needs an account either way.
Either way, once the connection is open, up to 1,000 files in a batch stream directly across it, each independently verified with a SHA-256 hash so you know what arrived matches exactly what was sent. If real-time isn't possible — say, the other person is offline — that's a genuinely different mode (a zero-knowledge stored link), not peer-to-peer, and worth understanding separately.
They're related but not identical. P2P describes the network path — bytes going directly between two devices. Encryption describes whether those bytes are unreadable to anyone in between. Relayium's realtime transfers are both: a direct (or relayed-but-encrypted) path, with the file sealed end-to-end regardless of which path it takes.
A small signaling server helps the two devices find each other's address — but it only ever sees connection-setup information, never file bytes. If a direct path can't be found, a TURN relay forwards the encrypted file data, but even then it only handles ciphertext it can't decrypt.
Some networks — often strict corporate firewalls or certain mobile carrier NATs — are built in a way that makes it impossible to discover a reachable address from outside information alone. That's rarer than it sounds, but when it happens, a relay is what keeps the transfer working instead of failing outright.
It can add some latency, since the relay is an extra hop the data passes through and it's a shared server rather than a dedicated one. But it's still generally faster than an upload-then-download flow, since there's no wait for the file to fully land on a server before the download side can start.
Two devices on the same network need no account at all. Sending across networks by pairing code needs the sender to sign in, but the person receiving never needs an account either way.
Curious what it feels like? Open Relayium on two devices and watch a direct connection form in real time.
Try Relayium now