Errors and low upload speed via Uplink CLI

[Alexey]

@mpw

In terms of encryption backend you mean uploading locally encrypted files or using rclone crypt?

restic, Duplicacy, Duplicati, Kopia, etc. - not the full list of backup tools with integrated encryption.
Or yes, rclone Crypt.
But I would suggest to use a backup tool instead, especially if you have a lot of small files, most of backup tools uses encryption, packing and compression, you may also backup only a difference since the last backup.

@mpw

In that case, wouldn’t that mean that these files cannot be accessed with any other tool than rclone configured with the right encryption? That’s of course more secure but it seems like it’s drastically reducing reusability across machines and development environments, esp. if you need to handle yet another set of passphrases that needs to be either strictly linked to a bucket or consistent throughout all the buckets (like the Storj encryption passphrase).

Yes, if you use encryption, you need to use the same tool and the same encryption phrase on any machine, as with Uplink too.
Regarding backups from different machines I would like to suggest to use Duplicacy, it’s designed for this case.
Regarding different encryption phrases, they are easily handled with a different access grants/s3 credentials for each case (and if we are talking about rclone - you may configure different remotes using the same API Key and the Satellite URL, but different encryption phrases, the same for S3 credentials). I use this feature myself - in the one bucket I store different objects using own encryption phrase for each set, i.e.

$ rclone lsd us:test
          -1 2000-01-01 07:00:00        -1 rclone
          -1 2000-01-01 07:00:00        -1 test

$ rclone lsd us1-gw-mt:test
           0 2000-01-01 07:00:00        -1 folder
           0 2000-01-01 07:00:00        -1 folder2
           0 2000-01-01 07:00:00        -1 share
           0 2000-01-01 07:00:00        -1 uplinks

@mpw

Seems pretty tricky to handle and could be a disaster waiting to happen when many people are uploading encrypted data and all it takes is for someone to accidentally use a different encryption password and all the data he ever uploaded becomes unusable.

if you would use tools, not the web UI (by the way, rclone has GUI), then it likely never happen - the access grant/s3 credentials will be stored locally on the source device. If you mean the integrated encryption of such tools - then you simple will be unable to get access to the encrypted content without an encryption phrase, the command will fail. However, you may use different encryption phrases too, and again - with a separate crypt remote for each encryption phrase.

Of course you still may use only native with integrated encryption into a protocol and/or S3 gateway without external encryption, because it’s secure enough - without your access key nobody can decrypt your access grant to get an access to your content in Storj. Just in case of native your access grant doesn’t stored even encrypted on our servers, unlike S3.