File transfer
Send a 100 GB file: why mainstream tools refuse, and how a direct peer-to-peer link doesn't
A 100 GB file blows past every mainstream limit. WeTransfer's free plan caps each transfer at **3 GB** (and even WeTransfer Pro, ~$15/mo, tops out at **200 GB** per transfer). [Tresorit Send](/glossary/end-to-end-encryption) — one of the few that is genuinely end-to-end encrypted — caps at **5 GB**. Filemail free is **5 GB** per transfer (paid Personal is also 5 GB; you need a Pro plan for 250 GB). Smash advertises "no file size limit" on its free tier, but any transfer over **2 GB is deprioritized and placed in a waiting queue**, and a 100 GB upload still has to go up to their servers and back down to your recipient. Across all of these, the file is uploaded to a third-party server, sits there for a retention window (often 3–7 days), and your throughput is bottlenecked by your upload bandwidth twice over — once to the server, once back down. For 100 GB, the free tiers simply refuse, and the paid ones turn a local copy into a days-long round trip through someone else's datacenter.
How RVNT does it
RVNT does not upload your file to a server at all. On a direct peer-to-peer connection between you and your recipient, there is no size limit — 100 GB or more streams straight device-to-device. The file is metadata-stripped, hashed with BLAKE3 for integrity, split into 512 KB segments, and each segment is encrypted with AES-256-GCM under a fresh per-file key before it leaves your machine. Because transfer is segmented and streamed, RAM use stays around O(512 KB) regardless of file size — your machine never holds the whole 100 GB in memory, and plaintext never lands on disk on either end. If the connection drops mid-transfer, RVNT resumes from the last verified segment instead of restarting from zero, which matters enormously at this scale. The recipient re-verifies the full BLAKE3 hash on reassembly, so a 100 GB file that arrives is provably the file you sent. The honest catch: all of this is true only on a direct link. If the two peers can't reach each other directly (e.g. both behind restrictive NATs or a VPN) and fall back to a relay, the transfer is hard-capped at 256 MB until resumable relay transfer ships. RVNT tells you this up front rather than stalling. So "any size" means on a direct connection — for a 100 GB file you and your recipient need to be able to connect directly, ideally on the same network.
How that compares
| Tool | Size cap | Keeps a copy on a server? |
|---|---|---|
| RVNT | No limit on a direct link (256 MB via relay) | No — direct, no server copy |
| RVNT (direct P2P) | No size limit (100 GB+); relay fallback capped at 256 MB | None — streamed device-to-device, no server copy |
| WeTransfer | 3 GB free per transfer; 200 GB on Pro (~$15/mo) | Yes — uploaded to WeTransfer, deleted after 3 days (free) |
| Tresorit Send | 5 GB per transfer | Yes — stored on Tresorit servers (but end-to-end encrypted) |
| Filemail | 5 GB free per transfer; 250 GB needs Pro | Yes — stored on Filemail servers, deleted after 7 days (free) |
| Smash | "No limit" free, but >2 GB is queued/deprioritized | Yes — uploaded to Smash servers |
Step by step
- Connect directly to your recipient For a 100 GB file you need a direct peer-to-peer link — the no-size-limit path. The most reliable setup is both devices on the same local network (LAN), where RVNT routes the transfer directly over your local interface. If you connect over the wider network and can only reach each other through a relay, the transfer is capped at 256 MB, so confirm you have a direct connection first.
- Select the file and send Pick the ~100 GB file in the conversation. RVNT strips metadata (EXIF, timestamps, device info where applicable), computes a BLAKE3 hash, and splits the file into 512 KB segments. Each segment is encrypted with AES-256-GCM under a fresh per-file key before any bytes leave your device. Memory use stays around O(512 KB) the whole time — your machine never loads all 100 GB at once.
- Let it stream — and resume if it drops Segments stream directly to your recipient with per-request acknowledgement backpressure. A 100 GB transfer takes real time and may span an interruption; if the connection drops, RVNT resumes from the last verified segment rather than restarting, so you don't lose hours of progress.
- Recipient verifies on arrival As segments arrive they're written into a pre-sized file; on completion RVNT recomputes the BLAKE3 hash over the whole file and compares it to the sender's hash. A match means the 100 GB file is intact and untampered. Plaintext never touched disk on either side until this verified write.
Frequently asked questions
Can I really send 100 GB with no size limit?
On a direct peer-to-peer connection, yes — there is no hard size limit, and the file streams device-to-device with around O(512 KB) of RAM use and no server copy. The critical condition is that you and your recipient connect directly (most reliable on the same local network). If you can only reach each other through a relay, the cap drops to 256 MB and a 100 GB file won't go through. We say this plainly because the relay limit is real.
What happens if the transfer gets interrupted halfway through 100 GB?
RVNT resumes from the last successfully verified segment rather than restarting from zero. Each 512 KB segment is content-addressed by the file's BLAKE3 hash plus its index, so the transfer picks up where it left off. This is specifically why peer-to-peer streaming with resume matters at 100 GB — a restart-from-scratch model would be unusable at that size.
Is my file stored on a server where it could be subpoenaed or breached?
No. Unlike WeTransfer, Filemail, or Smash, RVNT never uploads your file to a third-party server — there is no server copy and no retention window. Bytes go straight from your device to your recipient's, encrypted end-to-end the whole way. The trade-off is that both of you must be online and connected at once, because there's nowhere for the file to wait.
RVNT sends files directly device-to-device — encrypted end-to-end, no server copy, with resume-on-disconnect. It’s a messenger and a file-sharing network in one.