Comment by rudasn | Hacker News Reader

Comment by rudasn | Hacker News Reader

Parent Full thread

Cool, I've been working on similar my self. Not released yet, haven't had the time recently.

Curious as to why you store the data in the database in b64 as opposed to files on disk. What's the reasoning for that? Doesn't it make storage/backups/etc more complicated?

Not an expert myself, I opted for in browser encryption, in chunks, so as to avoid memory limitations (at least in some browsers, not FF yet), and in browser gzip so as to keep file size down and speed things up.

I find your niche quite interesting (journalists, whistleblowers) but given the high stakes of that perhaps an open source or more collaborative approach would be easier to promote.

Another idea I've tried out but not pursued, is some sort of browser extension/addon (I used nwjs, similar to electron), that offers client side encryption for any site (form field really). So you'd only post encrypted stuff to whatever service (email, reddit, hn, whatever) and only anyone with the key would get to read it (well, assuming they have the key and the same extension). Just throwing the idea out there, I'm sure others have thought about something along those lines before. The details to get it right are tricky (UX wise), but for your target audience it may be well worth the extra work.

Keep it up!:)

Thank you for the kind words and for taking the time to read the white paper. It's a good feeling when you spend time and effort on something and someone takes the time to go through it.

I opted for database storage to simplify the management of ephemeral data. For a solo project, and as someone still learning, this was a practical way to keep the codebase manageable while focusing on core features like encryption and token-based access control.

However, you should note, in case you missed it in the white paper, that messages and files are deleted upon view (for view-once links) or expiry, whichever comes first. This ensures that the ~33% storage overhead from base64 is temporary, as a file only occupies space until it’s accessed or expires.

That said, you’re absolutely right that base64 encoding adds unneccessay storage overhead and could complicate backups for large files. I also recognize that storing files on disk could be more efficient for large-scale use cases. As (or should I say IF?) the project scales with users, I’ll definitely consider optimizations like disk storage or compression (your gzip idea is great!).

If I run into optimization problems, then it means people are using my product, and that sounds like one of them good problems (Marlo Stanfield's voice).

Your suggestion of in-browser encryption is super compelling, especially to assure users of total privacy. I noted in my white paper that client-side encryption is a future goal to address the limitation of the current server-side encryption, and your approach aligns with that vision.

The browser extension idea is also fascinating, I did not think of that.

I’m open to collaboration (again, as mentioned in my white paper) and would love to discuss ideas for making ClosedLinks more auditable while still keeping it commercially viable/sustainable. I’d be excited to hear more about your project or explore ways we could collaborate on privacy-focused tools.

Thanks again for the encouragement and for sparking this discussion!

Just a +1 for browser encryption... you should be able to use pbkdf2 + aes to take an input passphrase with pbkdf2 to generate an aes key to then encrypt an input file in the browser, I'm not sure if you gain much via gzip before/after depending on the document that may already be a zip file (for word/oo, etc).

On the file storage, I generally recommend going straight to a cloud interface to separate storage backend from the actual storage medium... There are self-hosted options for an S3 compatible backend you manage, or you can use actual S3 or one of several other providers for S3 style storage.

Reply on news.ycombinator.com