Feature Requests

Allow supporting multiple mounts. In such case user could also mix their S3 mounts, with Rclone mounts and managed account (S3Drive) mounts.

Files > 100M are uploaded using multipart upload using 5MB chunks. If upload gets interrupted, next time when file gets uploaded we verify MD5 (only if E2E encryption is disabled) of each chunk so it doesn't gets reuploaded. The issues is that MD5 verification is relatively slow. If 10GB file was interrupted at 50%, then it means we need to verify 5GB of data which isn't instant. The idea is to store the file local modification date and trust that file contents hasn't changed if modification date hasn't changed. Using this pattern we could resume upload immediately. We could also resume upload of encrypted files given that we continue uploading chunks using the same nonce prefix (this is safe, because we're not reusing nonce. Yet to be uploaded chunks receive their own nonce counter). Finally implement exponential back-off retry for failed transfers (e.g. 400 bad request, 5xx errors and timeouts).

Add support for conflict resolution: --conflict-resolve string Automatically resolve conflicts by preferring the version that is: none, path1, path2, newer, older, larger, smaller (default: none) (default "none")

Once file is opened, we could cache the contents for a period of time, so when file is being opened again or downloaded, this would use user's bandwidth and would happen immediately. We could invalidate cache if change has happened on user's other device, user fetched S3 listing and last modified date no longer matches or when cache is removed manually.

At the moment once E2E is enabled with S3Drive, it applies to all locations globally. With Rclone there is a possibility to set custom prefix e.g. "photos/". Shall we allow to control what data is encrypted and which not? Our position so far is to encrypt everything by default (simple and secure), but there are couple reasons where users might not want to encrypt some locations. E.g. if they have high-quality videos, streaming (decrypting on the fly) them is a performance/battery hog.

It is required in order to provide translation to other languages. We will first try go ahead with Polish language as a test, given the founder's native knowledge and necessity to modify the app and extract language strings first. It will then make sense to focus on German translations, given that this is our 2nd user base just after US. Once we're ready with the technical hurdles we'll ask community for help with the translation.