HN Showcase
Back to browse
FileShot – zero-knowledge file sharing, 50GB/file free, no paywalls

FileShot – zero-knowledge file sharing, 50GB/file free, no paywalls

by GraysoftDev·Mar 4, 2026·2 points·0 comments
Visit ProjectView on HN

AI Analysis

●●●BangerBig BrainZero to OneShip It

True zero-knowledge file sharing: keys in URL fragment, server literally cannot decrypt even with access.

Strengths
  • •Architectural honesty: key lives only in URL fragment (#), never sent to server — cryptographically sound and verifiable in the whitepaper.
  • •No account friction for privacy features (password, expiry, burn-after-read) removes the 'create account to use encryption' contradiction that plagues competitors.
  • •Streaming chunk-by-chunk encryption (512KB) means the server never buffers plaintext, even internally — prevents accidental exposure during processing.
Weaknesses
  • •P2P mode requires both parties online simultaneously, limiting asynchronous sharing workflows.
  • •50GB free tier plus generous paid tiers may create scaling/infrastructure cost pressure as adoption grows (sustainability model unclear).
Category
Security
Target Audience

Anyone needing private file transfer without account friction; users skeptical of encryption claims by commercial services.

Similar To

Tresorit · Sync.com · ProtonMail Transfer

Post Description

I'm a college student developer who built FileShot because I was tired of "privacy-first" file sharing being marketing copy rather than an architectural commitment.

The thing that bothers me most about the current landscape: services claim zero-knowledge encryption, then require you to hand over your full name and email address just to password-protect a link. If the server genuinely never sees the key — why does it need to know who you are before you can use a basic feature? It doesn't. That's a conversion funnel, not a privacy decision.

How FileShot actually works: - AES-256-GCM runs entirely in the browser before any bytes leave your machine - Keys are generated client-side and exist only in the URL fragment (#key=...) - URL fragments are never sent in HTTP requests — the server is architecturally incapable of seeing your key - Password protection, expiry dates, download limits: all free, no account required - Accounts exist only for things that genuinely need server-side state: File Manager, history, persistent settings

What I've shipped as one person: - Web app (pure static HTML — no build pipeline, no framework bloat) - Native desktop app (Windows + Mac) - Chrome extension (screenshot capture, clipboard upload, page selection capture) - Android app

Free tier: 50GB per file. I have the infrastructure to support it, so I do. No file count limits, no bandwidth throttle, no artificial feature gates.

I built this because I genuinely believe a single developer with the right infrastructure can build something that competes with well-funded startups on the actual merits. Not to harvest data. Not to build funnels. Because doing it right felt more satisfying than doing it profitably.

Would love honest feedback — especially: what would it take for you to actually trust a service like this with sensitive files? What trust signals matter most to you?

Similar Projects