Zapfile Update: Critical Fixes, What You Asked For, and Where We Are Heading

We launched Zapfile in October 2025. Four months later, this is the first time I have sat down to write about what has actually happened since then — what we built, what broke, what users told us, and where we are going. I think it is overdue. So here it is, without the usual marketing polish.

Why We Built This in the First Place

The idea behind Zapfile came from a frustration I suspect a lot of people share but never articulate clearly: file sharing had become genuinely complicated in a way that made no sense.

Think about what it takes to send a 2GB video to someone today. WhatsApp will compress it into something unrecognisable. Email refuses to touch it. Google Drive will work but requires the recipient to have a Google account in the right state, consumes your storage quota, and leaves a permanently accessible link unless you remember to clean it up. Dropbox requires setup on both ends. Every option has a catch that turns a simple human act — handing someone a file — into a multi-step process with accounts, permissions, and storage management.

I built Zapfile on one rule: no signup, no limits, no middleman. You have a file. Someone needs it. It should go directly from you to them, and nothing should be stored anywhere after that. The file passes through our infrastructure for the duration of the transfer — typically a matter of seconds — and is purged immediately after the recipient receives the final byte. Sub-second retention. Not stored on disk. Not logged at the content level. Gone the moment delivery is confirmed.

That is still the rule everything else is measured against. Every feature request, every architectural decision, every tradeoff we make — does it serve that original idea or does it compromise it? If it compromises it, we do not ship it.

How Your Files Actually Travel

Before getting into what broke and what we fixed, I want to explain something about how Zapfile works that most people do not know — because it is the thing that makes everything else meaningful.

Your file never exists as a complete object on any server. Not ours. Not anyone's.

The moment a transfer begins, Zapfile breaks your file into packets. Each packet is relayed and discarded immediately — forwarded to the recipient and gone. By the time the last packet arrives at its destination, every fragment that passed through our infrastructure has already been purged. A complete, reassemblable copy of your file never sits anywhere except your device before the transfer and your recipient's device after it. There is no point in time where your full file is on any server waiting to be accessed, breached, scanned, or subpoenaed.

We are a pipe. Not a storage system. The difference matters.

On top of this, every packet in transit is protected by TLS 1.3 and AES-256 encryption — the same standards used to protect classified government and military communications worldwide. TLS 1.3 is the most current and secure version of the protocol that protects the connection itself. AES-256 is the encryption standard that has never been broken and is used by intelligence agencies, defence contractors, and financial institutions for their most sensitive data.

Put these two things together — packet-based relay with immediate discard, plus TLS 1.3 and AES-256 encryption on every fragment in transit — and the result is this: we cannot read your file. No one can. Not because of a privacy policy that could change tomorrow. Because of how the architecture works today.

What Users Reported: The Transfer Issues We Fixed

A few weeks after launch, reports started coming in about two specific transfer problems. I want to be honest about both of them because I think the way we handled them says something about how we intend to operate.

Issue 1: Transfers Dropping Mid-Way on Mobile Browsers

Several users reported that transfers would begin normally — progress bar moving, everything looking fine — and then cut out partway through with no clear error message. The problem appeared most consistently on mobile devices, particularly when the device was moving between WiFi and mobile data during a transfer.

After investigation, we traced it to session token handling in our transfer relay. When a mobile device switches networks mid-session — which happens automatically and silently on most phones when you walk away from a WiFi router — the session token tied to the original network connection was being invalidated. Our relay interpreted this as an abandoned session and terminated it on the server side, but the client-side had no meaningful way to surface that to the user. The transfer appeared to hang rather than fail cleanly.

The fix was implementing session persistence across network transitions. The session token now survives a network change for a defined grace period, giving the client time to re-establish the connection and resume the transfer rather than starting over. We also added a clearer client-side error state so that if a session does expire, users see an explicit message rather than a frozen progress bar.

This is fixed in the current release. If you experienced this issue and wrote to us about it — thank you. Your reports are what let us find it.

Issue 2: Large Files (Over 1GB) Timing Out Before Completion

The second issue was reported specifically by users transferring large files — typically 1GB and above — on slower or high-latency connections. Transfers would reach anywhere from 60% to 90% completion and then drop with a timeout error.

The root cause was an aggressive session timeout value we had set on our relay infrastructure. Originally configured for typical file sizes, the timeout was not accounting for the fact that a 2GB or 3GB file on a 10 Mbps connection could legitimately take 30–40 minutes to complete. Our relay was terminating sessions that had gone quiet for too long — even when "quiet" just meant the transfer was still in progress at a slow but consistent rate.

We increased the timeout threshold substantially and added adaptive timeout logic that extends the session window based on observed transfer speed and remaining file size. We also added retry logic so that if a relay session does drop, the client can attempt reconnection and resume from the last confirmed byte rather than restarting the entire transfer.

Large file transfers — including files several gigabytes in size — should now complete reliably across a range of connection speeds. If you are still experiencing this, please reach out directly.

The Blog Issue: What Happened and How We Fixed It

This one is on us completely and I want to be transparent about it.

In a previous release, a bug in our blog content seeding script caused articles to be published with unique titles but shared body content. The script was populating a content template variable that was not being correctly overwritten per post — so each new article entry in the database inherited the body content from the previous post, with only the title field updating correctly. The result was dozens of articles that looked distinct in the navigation and in search results but contained near-identical content when you actually read them.

We caught this after a couple of users mentioned that the guides all "seemed to say the same thing." They were right. We audited the full blog, confirmed the scope of the problem — 22 affected posts — and rewrote every one of them from scratch. Not lightly edited. Rewritten, with proper research, specific detail, and content that actually earns the title it carries.

The seed script has been patched. Before publishing, each post now validates content uniqueness by comparing a hash of the body against existing posts. If the hash matches anything in the database, the post is flagged for manual review rather than auto-published. That class of error cannot happen again in the current system.

If you read one of those early articles and found it unhelpful, I am sorry. The replacements are genuinely better. We are working through the rest of the content library with the same standard.

What You Are Asking For: Feature Requests

One thing that has been genuinely encouraging over the past four months is the volume of feature requests coming in. People are not just using Zapfile — they are thinking about it, and they have opinions about what it should do next. Here is what we are hearing most consistently.

Password-protected transfer links. This is the most requested feature by a significant margin. Users want to be able to add a passphrase to a transfer so that the link alone is not sufficient to download — the recipient also needs the password, shared via a separate channel. This is on our immediate roadmap.

Folder upload support. Currently, Zapfile handles files. Several users want to drag an entire folder — a project directory, a photo album, a set of assets — and send it without manually zipping it first. We hear this most from designers and developers. Coming.

Transfer progress notifications. When you send a large file and close the tab to do other things, there is currently no way to know when the recipient has finished downloading. Users want a notification — email or browser push — confirming delivery. We are looking at this.

QR code sharing. This one we have already shipped. Generate a QR code for your transfer link and the recipient can scan it directly from their phone — no copying links, no typing URLs, no fumbling with a long URL on a small keyboard. It is available now on every active transfer. Look for the QR icon next to your transfer link.

The Road Ahead: What We Are Building

I want to be honest that this is a roadmap, not a promise list with delivery dates attached. Things move based on what we learn. But these are the things we are genuinely building toward, roughly in order of priority.

Password-protected links. As mentioned — the most requested feature, so it is first. Add a passphrase at the time of transfer. Share the link one way, share the password another. The file is inaccessible without both.

Folder transfer support. Drag a folder, send a folder. We will handle the packaging and unpacking on both ends transparently. The recipient downloads the folder as a folder, not as a zip file they need to extract.

Transfer expiry control. Right now, transfers are live for as long as your session is active. We want to give senders control: set a transfer to expire in 1 hour, 6 hours, 24 hours, or 7 days. The link stops working after that window regardless of whether it has been downloaded. This is especially useful for sensitive files where you want to limit the access window explicitly.

End-to-end encrypted relay mode. Our current architecture passes files through our relay with sub-second retention — nothing stored, nothing logged at content level. The next step is adding a mode where files are encrypted client-side before they enter the relay, so our infrastructure handles only ciphertext. Even sub-second relay retention becomes irrelevant when the relay never has access to plaintext. This is more complex to implement correctly, but it is the right direction for users with strong confidentiality requirements.

Transfer delivery confirmation. Know when your file was downloaded — timestamp, not identity. The sender gets confirmation that delivery happened. The recipient's identity is never revealed. This is a deliberate design constraint: delivery confirmation without surveillance of the recipient.

Native mobile app (iOS and Android). The browser-based experience works on mobile, but background transfer support is limited — if you lock your phone mid-transfer, things can go wrong. A native app fixes this. Background transfers, proper push notifications, faster sharing from the camera roll. This is a bigger project and it is further out, but it is firmly on the roadmap.

The Part That Does Not Change

Four months in, the founding rule is the same as it was on day one: file sharing should be simple. No signup. No limits. No file sitting on a server somewhere that you have to remember to clean up. No storage quota. No account for your recipient to create just to download something you sent them.

Every feature above is being built inside that constraint. Password protection does not require an account. Folder support does not require an account. Expiry control does not require an account. The moment a feature requires either party to create an account as a precondition, we redesign it until it does not.

We are a small team building something we genuinely believe in. The feedback — including the critical feedback about the blog issues and the transfer bugs — has made Zapfile better. Keep it coming.

— Tanuja