I got tired of explaining privacy policies to people.
Every time I needed to send a file to someone, I had to pick a service and implicitly trust ...
For further actions, you may consider blocking this person and/or reporting abuse
Preety neat. Would check it with a friend
Thank you 🙏
The URL fragment trick for the key is clever. RFC 3986 guaranteeing fragments never hit the server is one of those spec details that most devs don't know about but it's incredibly useful for exactly this kind of thing.
One question though - what happens if someone shares the link through a platform that strips or modifies the fragment? I've seen some chat apps and email clients do weird things with URL fragments. Do you have any fallback or at least a clear error message for that case?
Also curious about the file size limits. AES-256-GCM in the browser can get pretty memory-hungry with large files since you're buffering the whole thing. Have you looked into streaming encryption with Web Streams API?
Good questions. Fragment stripping is a real edge case like some Slack previews and email clients do mangle URLs. Right now there's no graceful fallback, just a broken decrypt. It's on the list. Worth adding a clear error state that says "key missing from URL, ask the sender to resend the link."
On streaming encryption yes, Web Streams API with TransformStream is the right fix for the memory buffering issue. I buffered the whole file because it was simpler for a first version. Not sustainable for large files. I will tackle it.
Pretty neat! I am also building in this space but went the "serverless" aproach! Pretty wild what you can do with the go i/o readers and writers. you can actually start tcp connections, and encrypt them by wrapping them in custom Reader/Writers.
I think for the approach you took the veteran is croc but no UI, and not browser based.
That TCP wrapping approach is wild, would love to see what you’re building. The composability of readers and writers in Go was honestly the thing that made the language click for me.
And yeah croc is the obvious comparison, great tool. The browser-based approach was intentional though — the recipient needs zero setup. Just a link. That’s the whole point.
Hi, Ali, How are you?
I am a recruiter at techstacks-creator solution.
Currently we are looking for a contract developer for an existing project development.
Looking forward to discuss about that position with you.
Best, Ashlyn
Hi Ashlyn, happy to hear more if you can share the role details and budget upfront.
This is actually pretty cool. The "can't spy even if it wanted to" part is what got me, feels like more tools should be built with that mindset.
It actually could spy on you if it wanted to, it would just have to POST the url fragment.
It doesn't seem to do it without a small code change though.
Fair point and worth saying clearly. The zero-knowledge claim holds as long as the JavaScript running on the page is what it says it is. If I pushed malicious code that POSTed the fragment, the architecture breaks. That's why open source matters here as you can audit what's actually running. It's trust in the code, not trust in me.
JUST a UI note: it's nearly unreadable on a mobile phone
This is a really practical take. The memory/context management piece is something I've been wrestling with too — especially when building autonomous tools that need to maintain state across sessions.
Thanks, though I think you might be thinking of a different post. This one is specifically about client-side encryption for file transfer.