File transfer
Send files with no size limit
Mainstream "send large files" tools all share the same two problems: a hard cap, and a copy of your file sitting on their servers. As of June 2026 **WeTransfer**'s free tier allows only 3 GB — and just 10 transfers or 3 GB total in any rolling 30-day period, with links expiring after 3 days ([plan limits](https://wetransfer.com/help-center/subscriptions/plan-limits)). **Tresorit Send**, which is genuinely end-to-end encrypted, caps a share at 5 GB and expires it after 7 days or 10 downloads ([send.tresorit.com](https://send.tresorit.com/)). **Filemail**'s free tier is 5 GB per transfer ([filemail.com](https://www.filemail.com/)). **Smash** advertises "no size limit," but free transfers over 2 GB are deprioritized into a waiting queue ([Smash FAQ](https://faq.fromsmash.com/article/112-file-size-limit)). In every one of these, the bytes are uploaded to the provider's cloud and held there until the recipient downloads them — the provider, not just your recipient, ends up with a copy.
How RVNT does it
RVNT doesn't upload your file to a server at all. When two devices can reach each other directly, the file streams peer-to-peer straight from your device to the recipient's — there is no size limit on a direct connection, and no copy is ever stored on RVNT infrastructure (there is none for content). The file is metadata-stripped (EXIF/GPS/timestamps), BLAKE3-hashed for integrity, split into 512 KB segments, and AES-256-GCM encrypted with a unique per-file key before a single byte leaves your device. Streaming keeps RAM use to roughly O(512 KB) regardless of file size, so a 50 GB file works the same as a 5 MB one, and transfers resume from the last completed segment if the connection drops. The honest caveat, stated plainly: when the two devices can't connect directly (different networks, restrictive NAT) RVNT falls back to a relay, and relayed transfers are capped at 256 MB until resumable relay ships. "No size limit" is true on a direct link — on a relay it is 256 MB, and RVNT tells you so before the send rather than stalling. RVNT is pre-release and has not been independently audited.
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 (direct connection); 256 MB on relay fallback | None — streamed device-to-device, no content server exists |
| WeTransfer (free) | 3 GB per transfer; 10 transfers / 3 GB per 30 days | Yes — uploaded to WeTransfer cloud, link expires in 3 days |
| Tresorit Send | 5 GB per share | Yes — stored E2E-encrypted on Tresorit servers, expires 7 days / 10 downloads |
| Filemail (free) | 5 GB per transfer | Yes — held on Filemail cloud for 7 days |
| Smash (free) | No hard cap, but >2 GB queued/deprioritized | Yes — uploaded to Smash servers |
Step by step
- Open a conversation with the recipient Add the person as a contact (no phone number or email — identities are local Ed25519 keys claimed by proof-of-work) and open your direct chat. The file is sent inside the same end-to-end-encrypted channel, so the recipient is cryptographically the only party who can receive it.
- Attach the file Pick any file. RVNT strips metadata (EXIF, GPS, timestamps, camera/device info), computes a BLAKE3 hash, and splits the file into 512 KB segments — each encrypted with AES-256-GCM under a unique per-file key. No plaintext copy is ever written to disk.
- Send — direct when possible If your device can reach the recipient's directly (e.g. same network, or a reachable route), the encrypted segments stream peer-to-peer with no size limit and no server copy. If a direct path isn't available, RVNT falls back to a relay and tells you up front that relayed sends are capped at 256 MB.
- Recipient verifies and the transfer resumes if interrupted The recipient's device reassembles the segments, re-computes the BLAKE3 hash, and confirms it matches before showing the file — a mismatch is discarded. If the connection drops mid-send, the transfer resumes from the last completed segment rather than restarting.
Frequently asked questions
Is it really unlimited, or is there a hidden cap?
On a direct peer-to-peer connection there is genuinely no size limit, because nothing is uploaded to a server that would impose one — the file streams straight from your device to the recipient's in 512 KB segments using roughly constant memory. The one honest exception is the relay fallback used when two devices can't connect directly: relayed transfers are capped at 256 MB until resumable relay ships, and RVNT tells you before you send.
Does RVNT keep a copy of my file?
No. RVNT has no central server for content — files are streamed device-to-device and no plaintext ever lands on disk along the way. This is the core difference from WeTransfer, Filemail, Tresorit Send, and Smash, all of which upload your file to their cloud and hold a copy until it expires or is downloaded. On the recipient's device the file is stored in an encrypted-at-rest media cache, not in the clear.
What happens if the connection drops during a big transfer?
The transfer resumes from the last successfully completed segment rather than starting over. Each file is content-addressed by its BLAKE3 hash and split into 512 KB segments, so the recipient already knows exactly which segments it has and requests only the missing ones when the connection comes back.
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.