Add Proton Drive as Cloud Storage?

[Markoise]

Would it also be possible to add ProtonDrive as cloud storage?
There should be an API for third-party providers.

[EhudKirsh]

Hello @Markoise and welcome to AeroFTP.

I noticed that adding Proton Drive support to AeroFTP was already suggested before in https://www.reddit.com/r/cloudstorage/comments/1s9egl9/comment/odnufh8, so you might want to read what’s written there.
In a nutshell, Proton Drive lacks support for traditional protocols that would allow it to connect to 3rd party apps like AeroFTP, and this includes a native REST API as you suggest. Rclone connects to Proton Drive via an unofficial API, which, from my understanding, the Rclone community reverse-engineered. Using an unofficial reverse-engineered API isn’t part of AeroFTP’s philosophy, and at any rate, you can see at the top-right of https://rclone.org/protondrive that it’s tier 4, so it’s not a stable API.

With this in mind, now is a good opportunity to suggest to @axpnet an idea that has been on my mind for a while, which will nicely allow Proton Drive and other cloud drives to connect to AeroFTP. Proton Drive published its open-source CLI two months ago to the day.
This is a new development since the suggestion on Reddit, so it's worth re-examining it, also due to community feedback. Relevant links:

• https://proton.me/blog/proton-drive-cli
• https://github.com/ProtonDriveApps/sdk

AeroFTP already allows connecting to MEGA via MEGAcmd, which, except for MEGAcmd’s WebDAV, Rclone can’t do.
So my suggestion is the following: let’s build on this innovative aspect of AeroFTP which I mentioned in #285 with reference to MEGAcmd and create a new tab in the Add Service page called ‘CLI / CMD’ or some similar name. MEGAcmd already has a CMD badge in AeroFTP, and so can Proton Drive have, along with others like maybe even Filen. Or maybe the badge should be CLI.
Anyhow, this new tab should be for mostly open-source CLIs like those of Proton Drive and Filen, and other CLI that are at least
source-available like MEGAcmd, to stick with the theme of privacy, security and FOSS. To be clear, all the user will have to do is install the CLI of each cloud drive that they’re interested in, and possibly also log in through the CLI, and then AeroFTP will serve as the GUI for these CLIs, and support its features like calculating the total storage capacity, wrappesr/overlays, etc.

[axpnet]

Thanks both, and welcome @Markoise.

There should be an API for third-party providers.

That is the one piece that still does not exist, and @EhudKirsh is right about the state of play. Proton publishes no third-party Drive API. What they do publish is the Proton Drive SDK under MIT, and its README is explicit on two points: the SDK "is not yet ready for third-party production use", and authentication, session management and the user address provider are outside its scope. So even holding the SDK, a third-party client cannot log a user in today. The good news is that the same README now carries a commitment that was not there before: once the integration across Proton's own clients is stable and the new cryptographic model has landed, the SDK will be released for third-party use. Their current estimate for that window is end of 2026 or early 2027.

To be clear about intent, since this comes up as a question rather than a plan: Proton Drive is a roadmap objective for us, not a maybe. It has had a dedicated design document since May 2026, and it carries a commitment we made before anyone asked in public, which is that we will not reverse engineer the Proton protocol. That is the same position Ehud describes, and we put it in writing to Proton support in May 2026: we want to integrate through official means, whenever official means exist. What has been missing so far is not the will, it is a sanctioned way in.

Now to Ehud's suggestion, because it is the interesting part. Yes, and we are closer to it than the thread suggests: the pattern already exists in AeroFTP. Our MEGA provider is not a special case, it is a general shape. It implements the same StorageProvider trait every other protocol implements, and underneath it drives the official MEGAcmd binaries (mega-ls, mega-put, mega-get, mega-mkdir, mega-mv, mega-rm, mega-export and friends), with executable resolution across PATH and the usual install locations, per command timeouts, retries on transient failures, and console suppression on Windows. A Proton provider would be that same shape pointed at a different binary. So grouping these under a CLI or CMD category in the Add Service page is a natural extension rather than a new architecture, and we like the idea.

We checked that properly against the actual CLI rather than in principle, and the coverage is good. Of the methods our storage trait requires, the Proton CLI covers essentially all of them: filesystem list, info, upload, download, create-folder, rename, move, trash, delete, empty-trash, restore and copy, plus auth login, plus sharing and invitations on top. Current directory tracking is bookkeeping on our side, exactly as it already is for MEGAcmd.

There are six real gaps, and they are worth stating plainly because they shape what such a tab can honestly promise:

1. No quota command. The CLI registry has auth, fileSystem, photos and sharing, and nothing that reports account usage. So total storage capacity, which Ehud lists among the features, is the one thing we could not compute for Proton today.
2. No transfer progress. transferProgress.ts returns a no-op sink when stdout is not a TTY, so a CLI driven as a child process emits no progress at all. Either the progress bar sits still until a transfer completes, or we spawn under a pty and parse a spinner drawn for humans. This is the main user-visible cost.
3. One account per machine. The session lives in a single secret store entry, and multi-account is announced but not shipped, so multiple Proton profiles are not possible yet.
4. Browser-only sign in. There is no password on the command line, which is good for privacy and awkward for us: there are no credentials for AeroFTP to collect, store or export, and the connection flow becomes "install the CLI, then finish in your browser", unlike every other provider we support.
5. No ranged reads. No partial reads, no multipart, no resume, so features that read at an offset, such as mounting, would be limited or unavailable.
6. Cold start per command. The CLI is a Bun binary that re-initialises the SDK and its caches on every invocation, whereas MEGAcmd keeps a persistent server. For listing-heavy browsing that would be slow. The fix is to keep the CLI's own interactive shell open as a long lived process and talk to it, which is the equivalent of the MEGAcmd server.

One correction on the candidate list. Filen would not belong to that tab as things stand: our Filen provider is a native Rust implementation talking to the Filen API directly, and the only place we shell out is a small call for quota. So the tab would open with two members, MEGAcmd and Proton Drive, and grow from there.

Also worth saying: we would not bundle the Proton CLI. The user installs the official binary themselves and signs in themselves, exactly as they do for MEGAcmd today. That keeps the requests coming from Proton's own client, honestly identified as such, with the session in the OS secret store and credentials never passing through us.

The last piece is not technical. Proton's guidelines for personal and non-commercial projects are written about using the SDK, and we do not want to assume by ourselves that they extend cleanly to a third-party application automating the official CLI on a user's behalf. Their CLI announcement encourages use in scripts, cron jobs and pipelines, so orchestration looks like intended usage, but we would rather have their answer than our own reading of it. We are asking them on the support channel we already have open, before writing any code, and we will report their answer here whatever it is. If it is yes, this is buildable in a reasonable amount of work since the skeleton exists. If it is no, we wait for the SDK to reach general availability and integrate then.

And credit where it is due. @EhudKirsh welcomes practically every newcomer who opens a thread here, and does it with the context and the links already gathered, which is why this one turned into a design discussion within a day of being opened rather than sitting as a feature request. Thanks for that, and thanks for pushing the idea one level up, from one provider to a category. That framing is the right one, and it is the part of this thread we will carry into the roadmap.

[EhudKirsh]

I came across some interesting information by chance that I think might be relevant here.

In https://account.protonvpn.com/account-password, I saw this:

The 'Learn more' hyperlink links to this URL: https://proton.me/support/switch-two-password-mode.

I wonder if this is applicable here, to support Proton Drive and possibly other cloud drives that by default decrypt with the login password but might support having another password for that.