File transfer
Send files without uploading them to the cloud
Every popular "share a big file" service works by uploading your file to *their* cloud, generating a link, and storing the file there for days. The free tiers are tightly capped — **WeTransfer free is 3 GB per transfer and now throttled to just 10 transfers (or 3 GB total) in any rolling 30-day window**; **Filemail free is a hard 5 GB and only two transfers per day**; **Tresorit Send tops out at 5 GB per share**; **Smash advertises "no size limit" but parks anything over 2 GB in a waiting queue**. Worse than the caps is the architecture: even the end-to-end-encrypted senders (Tresorit Send, Smash) still hold a *ciphertext* copy of your file on their infrastructure until it expires. Your file's existence, its size, your IP, the recipient's IP, and the timing are all visible to — and logged by — the service. For most senders that's fine. If you specifically don't want a third party to ever possess a copy of the file, an upload-to-the-cloud model can't give you that, by definition.
How RVNT does it
RVNT doesn't upload your file anywhere. On a direct peer-to-peer connection, the file is metadata-stripped (EXIF/GPS/timestamps), split into 512 KB chunks, each chunk encrypted with AES-256-GCM under a fresh per-file key, and streamed straight from your device to the recipient's over the live encrypted session. The per-file key travels inside a Double Ratchet-encrypted message, so even the chunks in flight are useless to anyone observing. Because the transfer is direct, there is no server copy — no ciphertext sitting in a bucket, no expiry timer, no "your link was viewed" log. The pipeline is O(512 KB) RAM and resumable, so a dropped connection picks up from the last received chunk rather than restarting, and on a direct link there is no size limit at all. HONEST LIMIT: if the two devices genuinely can't reach each other directly (strict NAT, some VPNs), RVNT falls back to a relay to keep the transfer working — and a relayed transfer is capped at 256 MB until resumable relay ships. So "no server copy / any size" is the truth on a direct connection; on a relay you're capped at 256 MB and the relay handles encrypted bytes in transit. See File Transfer docs and the Architecture overview.
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 / transfer, max 10 transfers (or 3 GB total) per rolling 30 days | Yes — file stored on WeTransfer servers (held for 3 days) |
| Tresorit Send (free) | 5 GB per share (E2E encrypted) | Yes — encrypted ciphertext copy held on Tresorit servers until expiry (7 days / 10 opens) |
| Filemail (free) | 5 GB / transfer, 2 transfers per day | Yes — file stored on Filemail servers |
| Smash (free) | No hard size cap, but anything over 2 GB is queued | Yes — encrypted copy held on Smash servers until expiry |
| RVNT (direct P2P) | No size limit on a direct connection (256 MB if it falls back to a relay) | No — direct device-to-device, no server holds the file |
Step by step
- Add the recipient as a contact Both people install RVNT and exchange identities. There's no phone number or email — identity is a local Ed25519 keypair claimed by proof-of-work, so you're adding the actual device you intend to send to, not an account on someone's server.
- Open the conversation and attach the file Pick the file from the conversation screen. RVNT strips metadata (EXIF, GPS, timestamps, camera/serial info), computes a BLAKE3 content hash, and generates a one-time AES-256-GCM key for this specific file — none of this touches a server.
- Send — the file streams directly to their device On a direct peer-to-peer link the encrypted 512 KB chunks stream straight to the recipient with no upload step and no server copy. The per-file key rides inside the Double-Ratchet-encrypted message. If the connection drops, the transfer resumes from the last chunk received.
- Recipient verifies and decrypts locally Their device reassembles the chunks, recomputes the BLAKE3 hash, and checks it against the value in the message. A match proves the file arrived intact and untampered; it's then decrypted into their encrypted local media cache. No third party ever held the file.
Frequently asked questions
Does RVNT really keep no copy of my file?
On a direct peer-to-peer transfer, correct — the file streams from your device straight to the recipient's and is never uploaded to or stored on any RVNT server. There is no bucket, no link, and no expiry timer because there is nothing on a server to expire. The one exception is the relay fallback: if your two devices can't connect directly, a relay passes the encrypted bytes through in transit (capped at 256 MB), but it still isn't cloud storage — it doesn't retain the file.
How is this different from Tresorit Send or Smash, which are also encrypted?
Tresorit Send and Smash encrypt your file and then upload the ciphertext to their servers, where it sits until it expires (days, or a set number of opens). That's genuine end-to-end encryption of the contents, but the encrypted file — and the metadata around it — still lives on their infrastructure. RVNT's direct transfer never produces a server-side copy at all: the encrypted chunks exist only on your two devices and (transiently) in flight between them.
Is there really no size limit?
On a direct connection, no — the pipeline streams in 512 KB chunks using a fixed ~512 KB of RAM regardless of file size, and resumes from the last chunk if the connection drops, so a multi-gigabyte file is fine. The honest caveat: if the transfer has to fall back to a relay, it's capped at 256 MB until resumable relay ships. So 'any size' is a property of the direct link, not the relay.
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.