Would it be inaccurate to say that your fear is that Proton pulls an “Embrace, Extend, Extinguish” move?
No, it isn’t. But they never “embraced” as there was never direct IMAP to their servers, instead it’s a proprietary API serving data in a proprietary format.
I also see how that would make Proton like WhatsApp, which has its own protocol and locks its users in.
The problem isn’t that taking down the bridge would make Proton like WhatsApp. It’s the other way around, when they decided to build their internals with proprietary protocols and solutions instead eg. IMAP+SMTP they became the WhatsApp. Those things shouldn’t be addons or an afterthought, they should be bult into the core.
This clearly shows that making open solutions ranks very low their company and engineering priority list. If it was at the top they would’ve built it around IMAP instead.
I could download an archive of everything I have on Proton without a hitch.
Yes you can, but the data will come in more property formats hard to upload to anywhere else - at least for some of the data. They’ve improved this situation but it’s still less than ideal. In the beginning they would export contacts and calendars in some JSON format, I see they moved to vCard and iCal now.
I don’t disagree with you, I believe it as well. PGP is it stands is cumbersome.
The thing is that could’ve still implemented a easy-to-use, “just login and send email” type of web client and abstracted the user from the PGP complexities while still delivering everything over IMAP/SMTP.
You assume correctly, but when your mail client is trying to send an email instead of using SMTP to submit to their server, you’re using a proprietary API in a proprietary format and the same goes for receiving email.
This is well documented and to prove it further if you want to configure Proton in a generic mail client like Thunderbird then you’re required to install a “birdge”, a piece of software that essentially simulates a local IMAP and SMPT server (that Thunderbird communicates with) and then will convert those requests into requests their proprietary API understands. There are various issues with this approach the most obvious one is that it is an extra step, there’s also the issue that in iOS for eg. you’re forced to use their mail app because you can’t run the bridge there.
The bridge is an afterthought to support generic email clients and generic protocols, only works how and where they say it should work and may be taken away at any point.
Delivering your data over proprietary APIs doesn’t count as “open standards” - sorry.