[Feature Request] S3 Storage of Input/Output for various utility #511
Description
Describe the solution you'd like
While the converter is not intended to store converted files long-term, it would be nice for select users to be able to store both the input and output of a given conversion job both as a cache in the case of an input file, but i
61AE
n the case of the output file, offering a way of allowing longer term storage than that of a few hours/days, etc.
Files would or should be semi-anonymized (Use an SQL/SQLite DB to pair files to the user, that way it can be reversible but just looking at it you wouldn't know what file goes with what, and E2EE, allowing for users to have some faith that converted files are not easily accessible in a meaningful way.
My personal use case is I want to host this, and while I like being able to auto-delete over say, 72hrs, I am going to be hosting this on a cloud provider, and my storage there is a lot more of a delicate commodity than say, a Backblaze b2 instance @ 9$ USD/mo/TB. Much better to use as a backplane for file storage and would allow me to use higher limits so I have a temporary backup should something happen.
Additional context
Functionally this would mean one would be doing more upload/download operations on their host, as it has to not only be uploaded to the service, but potentially back and fourth between the remote S3 resource. However, it would mean a scalable amount of storage and flexibility, especially if I am converting larger files.
You'd probably want environment variables and config variables for the bucket credentials, and for the secrets you'd want to offer to accept creds via a file on the host (Allowing end users to keep the secrets out of config files, and ideally in a more secure manner.
If you want to offer anonymized files, you'll probably need a db to store the data it needs to translate, but this could be fairly straightforward, and doesn't need to be super secure. copy a checksum, and a reversible scramble of the filename via some manner, hell base64 or something, whatever is reverseable. SQLite would be easiest, but most people probably will want to use their DB of choice.
This is possibly a big ask, as it will expand the scope and add a decent amount of complexity, but it would make for a great featureset.