File transfer
Send a 50 GB file
Mainstream "send big files" tools work by uploading your file to **their** servers, then handing the recipient a download link — so your file sits, in full, on a third party's infrastructure, and the free tiers are nowhere near 50 GB. As of mid-2026 **WeTransfer free is capped at 3 GB per transfer** (and metered to 10 transfers or 3 GB total in any rolling 30-day window). **Tresorit Send** tops out at **5 GB** per upload free. **Filemail** free is **5 GB** per transfer, throttled to 2 transfers per 24 hours. **Smash** advertises "no file size limit" free, but anything over **2 GB** is de-prioritized into a waiting queue — so a 50 GB upload is technically allowed and practically miserable. Every one of these keeps a server-side copy of your bytes, and to actually push 50 GB through any of them you are paying for a Pro/Business plan. None of this is end-to-end private from the operator by default.
How RVNT does it
RVNT does not upload your file to a server at all. When two peers can reach each other directly, the file streams peer-to-peer with no size limit — 50 GB, 500 GB, whatever the link and disk allow. The pipeline (see File Transfer) strips metadata, chunks the file into 512 KB blocks, encrypts each chunk with a unique per-file key (AES-256-GCM) and verifies integrity with a BLAKE3 hash, then streams chunk-by-chunk so memory stays bounded (around 512 KB at a time) no matter how big the file is. Transfers resume from the last received chunk if the connection drops mid-way — essential at 50 GB, where a single drop on a server-upload tool means starting over. Nothing plaintext lands on disk, and there is no server copy: the only two machines that ever hold the bytes are yours and the recipient's. The honest catch: this "any size" guarantee holds only on a direct connection. When two peers can't connect directly (some NATs, VPNs, hostile networks) RVNT falls back to a relay, and relayed transfers are capped at 256 MB until resumable relay ships. A 50 GB file therefore requires a direct link — practically, that usually means the two devices are on the same network (LAN) or can otherwise reach each other directly. RVNT tells you honestly when a transfer would need the relay and is too big for it, rather than silently stalling.
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 connection) | No size limit (50 GB+), resume-on-disconnect | No — streams peer-to-peer, nothing stored on a server |
| WeTransfer (free) | 3 GB per transfer; metered to 10 transfers / 3 GB per 30 days | Yes — uploaded to WeTransfer servers |
| Tresorit Send (free) | 5 GB per upload | Yes — stored encrypted on Tresorit servers |
| Filemail (free) | 5 GB per transfer; 2 transfers per 24h, 7-day expiry | Yes — uploaded to Filemail servers |
| Smash (free) | No hard cap, but >2 GB is de-prioritized into a queue | Yes — uploaded to Smash servers |
Step by step
- Get a direct connection between the two devices A 50 GB transfer needs a direct peer-to-peer link, not the relay. The simplest reliable way is to put both devices on the same network (the same Wi-Fi or LAN), where RVNT routes the transfer directly over the local network rather than falling back to a relay.
- Pick the file and let RVNT prepare it Select the ~50 GB file to send. RVNT strips metadata (EXIF/GPS/timestamps where applicable), computes a BLAKE3 content hash, and chunks the file into 512 KB blocks. Each chunk is encrypted with a unique per-file key (AES-256-GCM); the per-file key travels to the recipient inside the Double Ratchet-encrypted message, not over any server.
- Stream the file peer-to-peer Chunks stream directly to the recipient, who writes them straight to disk as they arrive — RAM stays bounded (~512 KB at a time) regardless of total size. If the connection drops, the transfer resumes from the last successfully received chunk instead of restarting the full 50 GB.
- Verify on arrival Once all chunks land, the recipient's device recomputes the BLAKE3 hash of the reassembled file and compares it to the sender's hash. A match means the file is intact and untampered; a mismatch is discarded and flagged. No copy of the file was ever held by a third party.
Frequently asked questions
Can I really send a 50 GB file with no size limit?
On a **direct** peer-to-peer connection, yes — there is no built-in size cap, and the streaming pipeline keeps memory use around 512 KB at a time regardless of total file size. The honest condition is that it must be a direct link. If the transfer falls back to a relay, it's capped at 256 MB, so a 50 GB file requires the two devices to connect directly (most easily by being on the same network).
What happens if my connection drops halfway through 50 GB?
The transfer **resumes from the last successfully received chunk** rather than restarting. Because files are content-addressed by BLAKE3 hash and chunked into 512 KB blocks, RVNT knows exactly which chunks already arrived and continues from there — which is the whole point at 50 GB, where a restart-from-zero would be painful.
Does RVNT keep a copy of my file on a server like WeTransfer does?
No. There is **no server copy.** The file streams directly between your device and the recipient's; the only two machines that ever hold the bytes are the two of yours. Nothing plaintext is written to disk, and the per-file encryption key is delivered inside an end-to-end-encrypted message, not via any server.
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.