Update: i went to reddit because there was an AMA from proton . There, they said: *The only reason why our Linux clients are lagging from a development is simply that it is extremely difficult to hire Linux Desktop developers.
So for anyone reading this, if you are based anywhere in the European timezone and willing to take up on the challenge, apply here: https://boards.eu.greenhouse.io/proton/jobs/4140067101*
Still reading all the replies, very greatful for the tips and responses, thank you all!
===
Thought i would share this with you all:
I contacted Proton for a technical issue and decided to also ask about their plans for Drive for Linux. Their response:
Proton Drive on Linux: Regarding the availability of a Proton Drive client for Linux, this is a common feature request that many users have expressed interest in. Our team is aware of the growing demand for a Linux client. While we currently do not have an ETA for when a Linux client might be available, we have not ruled out the possibility of working on it in the future.
I’m very disappointed, since i’m probably going to switch to Linux over the weekend.
I’m not familiar with Proton drive but with Google drive you can use a vfs cache if I’m not mistaken to make things faster.
@8rhn6t6s There are some caching which need to be enabled with the protondrive rclone mounting. But it is still slow.
Remember that non-E2EE storages (such as Google Drive, AWS/S3, etc) can do the upload a lot faster as a starting point, as there is no client-side encryption of the data being uploaded (and the reverse; decrypting downloaded data). This decryption/encryption happens in the protondrive “module” in rclone. On top of that comes that files are split up into “chunks” which are transferred via separate HTTP calls. And I have no idea (aka "have not read the code) how the unlock key of the PGP key is handled in rclone. All of these things combined together impacts the performance.
That said, I’ve had a quick test on a Windows computer with Proton Drive installed. It wasn’t blazingly fast there as well, but still felt faster than rclone.
My guess is that it’s partly that the rclone implementation has room for improvements on how the Proton Drive server-side APIs are called and some of it is related to crypto implementation performance.
For example, I dunno if the Proton Drive APIs support HTTP/2 protocol or QUIC … And I dunno if the rclone supports them as well. Just in this aspect there are lots of room to cut down on the “connection handshake” as HTTP/2 and QUIC supports more efficient handshakes and can also have multiple streams sending data in parallel - using a single handshake. If the native Proton Drive app on Windows implements this, that may explain some of the performance differences.