File transfer
Peer-to-peer file transfer: send large files straight to one person, no server in the middle
Mainstream "send a big file" tools are not transfers at all — they are **uploads to someone else's server**, and the recipient downloads a copy from that server. That model fails large-file sending in two ways. First, hard caps: WeTransfer's free plan is now **3 GB per transfer** and throttled to 10 transfers (or 3 GB total) every 30 days after the 2024 Bending Spoons acquisition; [Tresorit Send](https://support.tresorit.com/hc/en-us/articles/360007285474-Use-Tresorit-Send) and [Filemail](https://www.filemail.com/features/upload-files) free both stop at **5 GB**; [Smash](https://faq.fromsmash.com/article/112-file-size-limit) advertises "no limit" free but queues and de-prioritizes anything over 2 GB. Second, and worse for privacy: your file lands on infrastructure you do not control, is retained for days (then auto-deleted, often before your recipient grabs it), and — outside the end-to-end-encrypted services — can be scanned. Browser "P2P" tools like WebRTC drop-sites look direct but usually still relay bytes through a TURN server when a direct connection can't form, and both tabs must stay open the entire time or the transfer dies.
How RVNT does it
RVNT is native peer-to-peer, not a browser tab and not an upload service. When two RVNT apps establish a direct connection, the file streams device-to-device in 512 KB segments: metadata-stripped (EXIF/GPS/camera/timestamps), BLAKE3-hashed for integrity, and encrypted before it leaves your machine. There is no upload to a third-party server and no server-side copy of your content — RVNT's only server holds public prekeys and discovery data, never file bytes. The pipeline streams with O(512 KB) RAM regardless of file size (a 50 GB file uses the same memory as a 50 MB one), the plaintext never touches disk, and an interrupted transfer resumes from the last verified segment instead of restarting. CRITICAL HONESTY: "no size limit" is true only on a direct connection. When two peers cannot reach each other directly (carrier-grade NAT, some VPNs) RVNT falls back to a relay, and relayed transfers are capped at 256 MB until resumable relay ships. The app tells you plainly when you've hit that path and asks you to get on the same network for the big stuff. RVNT is also pre-release and not independently audited — see the caveats.
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 on a direct connection (256 MB on relay fallback) | None — streams device-to-device, no third-party server copy |
| WeTransfer (free) | 3 GB per transfer, 10 transfers / 3 GB per 30 days | Yes — uploaded to WeTransfer servers, link expires in 3 days |
| Tresorit Send (free) | 5 GB per transfer (E2E encrypted) | Yes — encrypted, but stored on Tresorit servers until download/expiry |
| Smash (free) | "No limit" but >2 GB is queued / de-prioritized | Yes — uploaded to Smash servers, expires in 7 days |
Step by step
- Open the conversation with your recipient Both people need RVNT installed and connected as contacts. For an unlimited-size transfer, get both devices a direct path to each other — the simplest is the same Wi-Fi/LAN, which routes the connection directly rather than through a relay.
- Attach the file Pick the file from your device. RVNT strips metadata (EXIF, GPS, camera model, timestamps), computes a BLAKE3 hash of the cleaned file, and generates a fresh random per-file encryption key — all locally, before anything is sent.
- Send — it streams directly, encrypted The file is split into 512 KB segments, each AES-256-GCM encrypted, and streamed straight to the recipient's device over the encrypted P2P connection. Nothing is uploaded to a third-party server and no plaintext copy is written to disk on either end.
- Recipient verifies and the transfer resumes if interrupted The recipient's app reassembles the segments and checks the BLAKE3 hash against the sender's — a mismatch means corruption or tampering and the file is rejected. If the connection drops mid-transfer, it picks up from the last verified segment instead of starting over.
Frequently asked questions
Is this actually peer-to-peer, or does it relay through a server like browser "P2P" tools?
When a direct connection forms, it is genuinely device-to-device with no third-party server touching your file bytes — that's the no-size-limit path. RVNT does have a relay fallback for peers that can't reach each other directly (carrier-grade NAT, some VPNs), and on that path transfers are capped at 256 MB and the app tells you so. Unlike WebRTC browser drop-sites, RVNT is a native app, so you don't have to keep a tab open and the transfer survives the app moving to the background.
What's the real maximum file size?
On a direct connection there is no enforced size cap — the transfer streams in 512 KB segments using a constant ~512 KB of RAM, so a 50 GB file is mechanically the same as a 50 MB one, and resume-on-disconnect means a dropped link doesn't force a restart. The 256 MB cap applies only to the relay fallback. By contrast, free mainstream tools top out at 3 GB (WeTransfer) to 5 GB (Tresorit Send, Filemail) per transfer.
Does a copy of my file sit on a server somewhere?
No. RVNT streams content directly between the two devices; the only server in the system holds public prekeys and peer-discovery data, never your file contents. Plaintext is never written to disk on either end. Upload-based tools like WeTransfer, Tresorit Send, and Smash necessarily store your file on their servers until the recipient downloads it or the link expires (3–7 days), which also means it can vanish before they grab it.
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.