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!

Yea, the email part was a problem I mentioned in the white paper. Problem was I couldn't think of a way to enforce plan limits while making the subscription model work. If usernames, then they could just abuse it by creating new usernames each time. But I understand you. Maybe if you have some suggestions?

So regarding the sender and recipient, let's say I wanted to send you something. A message or a file, but wanted to maintain plausible deniability on if I sent it. I wanted a way of doing this, and the solution I came up with was that the link you receive publicly is not the link you land on to access the message or file. Anyone who lands on the publicly shared link, gets redirected to a new url each time.

But even without the deniability angle, it could be a way of sharing files with one time links. The links work once. And there's password protection, if enabled.

The implementation might not be perfect, but open to ideas, of course.

On, and there's API feature for generating links, and uploading files - for what it might be worth.