File transfer
Send a 1 TB file
At ~1 TB, consumer file-transfer services simply do not apply. WeTransfer's free tier is **3 GB per transfer** (raised from its long-standing 2 GB cap, now with a monthly quota and 3-day expiry) — about 0.3% of a terabyte. Tresorit Send, the privacy-focused option, caps at **5 GB**. Filemail's free tier is **5 GB** (2 sessions per 24 hours). Smash advertises "no size limit" on free, but anything over 2 GB is **deprioritized into a queue**, files are stored on Smash's servers, and free transfers are **deleted after 7 days**. The deeper problem is structural, not just numeric: every one of these works by uploading your file to *their* servers, where it sits — encrypted or not — for a retention window, then sends the recipient a download link. For a terabyte that means a full upload to a third party and a full download back out, doubling the transfer time and putting your data on infrastructure you do not control. To get even close to 1 TB you are pushed onto paid Enterprise tiers (Smash Team tops out at 1 TB per transfer; Filemail Business removes the file-size limit) — still server-relayed, still a copy you do not hold the keys to.
How RVNT does it
RVNT does not upload your file to a server at all. When two peers can connect directly, the file is streamed peer-to-peer straight from your disk to theirs. There is no size limit on a direct connection — a terabyte is the same pipeline as a megabyte, just longer. The file is split into 512 KB segments, each encrypted with a key derived per-chunk from a unique per-file key (AES-256-GCM), so only about half a megabyte of plaintext is ever in memory at once and no plaintext copy is written to disk on either side. A BLAKE3 hash of the whole file is checked on arrival, so the recipient knows the terabyte that landed is byte-identical to what you sent. Because the protocol is content-addressed by that hash plus chunk index, an interrupted transfer resumes from the last successfully received chunk instead of restarting — essential when a transfer of this size can run for hours. There is no server copy and no retention window: the data exists only on your two devices. EXIF and other metadata are stripped from supported media before sending. The honest constraint: this "no limit" applies on a direct peer link. If your two devices cannot reach each other directly and the transfer has to fall back to a relay, RVNT caps it at 256 MB until resumable relay transfer ships — so a 1 TB send genuinely requires a direct connection (same LAN, or a routable path between the two peers).
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 |
| WeTransfer (free) | 3 GB per transfer (monthly quota, 3-day expiry) | Yes — stored on WeTransfer servers |
| Tresorit Send | 5 GB per transfer | Yes — end-to-end encrypted, but held on Tresorit servers |
| Filemail (free) | 5 GB per transfer (2 sessions / 24 h) | Yes — stored on Filemail servers |
| Smash (free) | No hard cap, but >2 GB is queued/deprioritized; 7-day deletion | Yes — uploaded to Smash servers |
| RVNT | No size limit on a direct connection (256 MB on relay) | No — direct peer-to-peer, no plaintext on disk |
Step by step
- Confirm a direct connection to your recipient A ~1 TB transfer needs a direct peer-to-peer link, not a relay. The simplest reliable case is both devices on the same local network. Add the recipient as a contact and confirm the conversation shows a direct connection rather than a relayed one before starting — on a relay, RVNT enforces a 256 MB cap and the terabyte will not go through.
- Attach the file and let RVNT strip and segment it Pick the file in the conversation. RVNT strips metadata from supported media (EXIF/GPS, timestamps, device info), computes a BLAKE3 hash for integrity, and splits the file into 512 KB segments. Each segment is encrypted with AES-256-GCM under a key derived from a unique per-file key — nothing is staged as plaintext on disk.
- Stream it directly, peer-to-peer Segments stream straight from your disk to the recipient's over the direct link. Only ~512 KB of plaintext is in memory at a time, so RAM use stays flat whether the file is 1 GB or 1 TB. No copy is uploaded to any server, and there is no retention window — the data lives only on your two devices.
- Let it resume on interruption, then verify the hash A multi-hour transfer will hit network blips. RVNT resumes from the last successfully received chunk instead of restarting. When the last segment lands, the recipient recomputes the BLAKE3 hash over the whole file and compares it to the one you sent — a match confirms the terabyte arrived byte-for-byte intact and untampered.
Frequently asked questions
Can RVNT really send a 1 TB file?
On a direct peer-to-peer connection, yes — there is no size limit, and memory use stays flat (~512 KB at a time) because the file is streamed in 512 KB segments rather than loaded whole. The practical requirement is a direct link between the two devices (commonly the same local network). If the transfer has to use a relay, it is capped at 256 MB, so a terabyte will not go through a relay.
Where does the file get stored during the transfer?
Nowhere except your two devices. Unlike WeTransfer, Tresorit Send, Filemail, or Smash — all of which upload your file to their servers and hold it for a retention window — RVNT streams the data directly peer-to-peer. No server copy is made, no plaintext is written to disk on either side, and there is no expiry timer because there is nothing on a server to expire.
What happens if the connection drops halfway through a terabyte?
The transfer resumes from the last successfully received chunk rather than starting over. Each 512 KB segment is content-addressed by the file's BLAKE3 hash plus its chunk index, so RVNT knows exactly which segments already arrived. When the final segment lands, the recipient recomputes the BLAKE3 hash over the whole file to confirm it is byte-for-byte identical to the original.
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.