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.