I would highly suspect this is because they don’t want to handle encryption and decryption on their servers where ever they can. Yes they need encryption for emails they receive but for every thing else they want to have as end to end protected as they can. Which means client side encryption and decryption for almost every thing. That is the big feature that a lot of people are buying into from them.
All these protocols don’t feal with encryption on the client at all. Which means if they supported them they would need to handle encryption and decryption on the server side. Which I doubt they want to do and likely work hard to avoid at all.
they could implement a local translation layer that still uses from these. Ok, then it would potentially be a daemon, but it would be able to be used by all existing linux programs capable of interfacing with these protocols.
They could at least have implemented a shell that translates the linux commands to their api, like hetzner. cp,mv,sha, etc. and is interactive…
They need a basic remote API and SKD first. Now we have that anyone can implement these local daemons/translation layers if they want to. This is still early days.
They could at least have implemented a shell
They do have an interactive shells:
You can also run interactive shell. Just type ./proton-drive and then the commands directly.
Though the commands are not the same as Linux equivalents that is IMO not a big concern. Similar things like AWS S3, or even ftp also don’t have the exact same commands. It is really a trivial thing to learn how it works.
And again, anyone is free to build on this now if they want to.
I would not be surprised to see a fuse fs popup at somepoint around this.
I would highly suspect this is because they don’t want to handle encryption and decryption on their servers where ever they can. Yes they need encryption for emails they receive but for every thing else they want to have as end to end protected as they can. Which means client side encryption and decryption for almost every thing. That is the big feature that a lot of people are buying into from them.
All these protocols don’t feal with encryption on the client at all. Which means if they supported them they would need to handle encryption and decryption on the server side. Which I doubt they want to do and likely work hard to avoid at all.
they could implement a local translation layer that still uses from these. Ok, then it would potentially be a daemon, but it would be able to be used by all existing linux programs capable of interfacing with these protocols.
They could at least have implemented a shell that translates the linux commands to their api, like hetzner. cp,mv,sha, etc. and is interactive…
They need a basic remote API and SKD first. Now we have that anyone can implement these local daemons/translation layers if they want to. This is still early days.
They do have an interactive shells:
Though the commands are not the same as Linux equivalents that is IMO not a big concern. Similar things like AWS S3, or even ftp also don’t have the exact same commands. It is really a trivial thing to learn how it works.
And again, anyone is free to build on this now if they want to.
I would not be surprised to see a fuse fs popup at somepoint around this.