Feature proposal: option to store download links at server side (opt-in, for easy retrieval of non-sensitive files)

[remiberthoz]

Hi,

Thank you for creating Enclosed, it’s a great tool, and very easy to self-host!

I often use it to transfer files between devices: a typical scenario for me is moving a document from my personal computer to a public computer at work, just so I can print it. In these cases, after uploading a file, I also need to send the generated URL to the other device (usually via email).

Requirement to share the URL separately is part of the design of Enclosed, notably because the base key is included in the URL and unknown to the server. For some non-critical files, however (e.g. public documents) secrecy of the key isn’t required. In these situations, it would be very convenient if the Enclosed server could store and display the download link, avoiding having to send it manually from one device to the other. For example, a “Recent uploads” section on the homepage would make the workflow smoother.

I realize this breaks part of the zero-knowledge model, but since it would be optional and opt-in, I believe it could be useful for certain scenarios like the one described above.

Concretely, I am imagining an additional button on the "Note created successfully" page, something like “Display download link publicly”. If clicked, the client would in fact send the download link (including the base key) to the server, allowing it to be shown in a small “Recent uploads” section of the homepage, for easy retrieval on other devices. I would include a user warning tool-tip next to the button, describing how the feature breaks the zero-knowledge model. The feature could, also, be disabled at the server level ; and always disabled for password-less uploads (password-less uploads with a public link could effectively be read by anyone).

Would you consider such a feature compatible with the philosophy of Enclosed? If so, I’d be happy to start working on a pull request. I believe I could handle the client-side of things, but I foresee difficulties on the server-side. I am not familiar with the various storage backends.

---

I'll mention that I've seen you agree with (in #364):

This is unlikely to be implemented as it would involve the server having knowledge of the note URL and therefore encryption key, defeating the purpose of the e2e encryption.

and I realize that my proposal is aligned with this failure of the e2e scheme for password-less uploads. Maybe I should take it as a definitive no, but I'm taking a chance with the opt-in idea.

---

Let me know what you think. Thanks again for the project!