Frequently Asked Questions

Is Tallow really end-to-end encrypted?

In End-to-end encrypted mode, yes. Your files are encrypted on your device before being sent to the relay. The relay only forwards ciphertext. Even if the relay server is fully compromised, your files remain confidential. The encryption uses AES-256-GCM with keys derived from a hybrid ML-KEM-1024 + X25519 key exchange. In Transport-only mode there is no end-to-end encryption: the relay carries the bytes as they are, so do not use that lane for content you need sealed in transit.

What does “post-quantum” mean?

Post-quantum cryptography uses algorithms believed to be resistant to attacks by quantum computers. Tallow uses ML-KEM-1024 (FIPS 203), a lattice-based key encapsulation mechanism standardized by NIST. This protects your transfers against “harvest now, decrypt later” attacks where an adversary records encrypted traffic today and decrypts it when quantum computers become practical.

How big can transferred files be?

Up to 1 GiB (1 GB) per room, nothing stored. The cap is enforced in your browser before the offer is sent, and the relay keeps no copy — the room closes when the transfer completes. Within that cap, the practical bound is your browser:

• End-to-end encrypted mode decrypts in the browser and uses the direct device-to-device path — verified byte-exact at 256 MB, 512 MB and 1 GB. If a direct connection can’t be established, it falls back to the relay automatically, still end-to-end encrypted.
• Transport-only (streamed) mode writes straight through to disk, so memory is not the constraint; the 1 GiB (1 GB) per-room cap still applies.

Either way the sender must keep the tab open until the receiver finishes; when in doubt with very large sets, split them into a few rooms.

Can the relay see my files?

In End-to-end encrypted mode, no. The relay operates on a zero-knowledge principle. It receives room IDs (one-way derivations of the room code — never the code itself) and forwards encrypted bytes. In that mode it cannot:

• Read your file content
• See your filenames
• Access your encryption keys
• Correlate transfers to identities (especially with Tor enabled)

In Transport-only mode the relay is the data path: it carries the bytes as they are, so it can read the file content. It still receives only the room ID — never the code — and never your encryption keys.

Is Tallow open source?

Yes. Tallow is licensed under AGPL-3.0 and the source release is being finalized. Today you can audit the running system directly: see the self-test and the transparency notes; cryptographic details live in the Security Model.

How do I verify transfer integrity?

Tallow verifies integrity as it goes. In End-to-end encrypted mode each chunk is authenticated via an AES-GCM tag bound to its index (so reordering fails too), and a tampered chunk fails the transfer. On the CLI lane the complete file is additionally verified against a BLAKE3 Merkle tree root; the browser sender does not send a Merkle root today, so in the web app integrity rests on the per-chunk tags plus the transport — and in Transport-only mode, on the transport alone. No manual verification is needed.

Can I self-host the relay?

Yes. The relay server (tallow-relay) is a separate binary that you can build and deploy on your own infrastructure. See the Self-Hosting Guide for detailed instructions including systemd service files and Docker deployment.

Does Tallow work offline?

Yes, an internet connection is required — both devices must reach the relay server to join the room, even when the file data itself then travels directly between same-network devices (peer-to-peer).

What browsers are supported?

The homepage send module requires WebAssembly and WebSocket support:

• Chrome 90+
• Firefox 89+
• Safari 15.2+
• Edge 90+ (Chromium-based)

Mobile browsers are supported on both iOS (Safari) and Android (Chrome).

How is Tallow different from other file transfer tools?

Is there a file size limit?

Up to 1 GiB (1 GB) per room, nothing written to disk — the client caps the total selected-file bytes for a room before the offer is sent. Within that cap the practical bound is your browser: End-to-end encrypted mode decrypts in the browser and its direct device-to-device path is verified byte-exact at 256 MB, 512 MB and 1 GB, while transport-only mode streams straight to disk. The sender keeps the tab open until the receiver finishes.

Can I use Tallow without the relay?

Yes — for the data path. Tallow supports peer-to-peer connections via WebRTC (End-to-end mode, and Transport-only mode when both devices are on the same network): the file data travels directly between the devices, and the relay only introduces them and sets up the connection (both devices still need to reach the relay for that introduction). The Relay-only (hide your IP) setting forces everything through the relay in the browser, and the CLI’s --no-p2p flag does the same.

How secure is the room code?

Room codes are six-character passcodes from a 32-symbol alphabet (A–Z without I/O, digits 2–9), drawn with a CSPRNG — 2³⁰ codes by design: a short-lived handle for an ephemeral session, not a long-term secret. Safety comes from the layers: a password-authenticated key exchange (no offline guessing), relay join limits, room expiry, and a memory-hard room identifier (Argon2id) that resists reversal. Use --password for stronger sessions. Legacy word-phrase codes still join; that path is deprecated.

How do share links work?

The /s/<token> short link carries a derived token — never the room code itself. The token is resolved in your browser: the server serves a static page and keeps no token-to-room mapping, and short-link paths are excluded from access logs. Anyone holding the link can join, just like anyone holding the code.