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.
Hmm. I think not using standard protocols but an ad-hoc API may result in vendor lock-in, which yes, is a bad thing (though it doesn’t mean it’s generated). For example, one of my clients has backups in AWS, and he initially asked me to upload them using standard sftp, but then we saw the bill for using the sftp add-on and had to immediately rewrite the uploads using the free but vendor-specific CLI.
Regarding the docs, I see they put them in help texts, which tbh isn’t that bad, but indeed duplicating them online for convenient search would be obviously better. For my library, I put the docs all in the readme like many libs did in early years of Node.js (and I liked the docs that way), without an extra documentation website, though I have a landing page showing quick start examples.
What are the obvious signs of vibe code in that repository? Something about the README markup seems off, but other than that I don’t yet see it.
I haven’t read the code, I only judged by their cli usage and docs. It’s ridiculously low-effort.
edit: Hetzner for comparison: https://docs.hetzner.com/storage/storage-box/access/access-overview/
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.
So if something does not have full feature set at launch, it’s vibe coded?
given how low effort it is, I said it looks like a vibe coded project. Feel free to create your narrative here
Hmm. I think not using standard protocols but an ad-hoc API may result in vendor lock-in, which yes, is a bad thing (though it doesn’t mean it’s generated). For example, one of my clients has backups in AWS, and he initially asked me to upload them using standard sftp, but then we saw the bill for using the sftp add-on and had to immediately rewrite the uploads using the free but vendor-specific CLI.
Regarding the docs, I see they put them in help texts, which tbh isn’t that bad, but indeed duplicating them online for convenient search would be obviously better. For my library, I put the docs all in the readme like many libs did in early years of Node.js (and I liked the docs that way), without an extra documentation website, though I have a landing page showing quick start examples.