3 ms·

Not implementing IMAP because it's a poor fit is a fair excuse. It's not like they could've took some pre-existing imapd implementation, slapped a few lines of

Not implementing IMAP because it's a poor fit is a fair excuse. It's not like they could've took some pre-existing imapd implementation, slapped a few lines of glue code and called it a day. It would've probably required a fair amount of engineering time, which is better spent on something more productive for their declared goals. The problem I see is not that they're not providing IMAP access, but that they're not providing any alternatives except for their product. Would the attitude be "here is a living API spec we currently use, subject to changes without warning, some endpoints not really documented (documentation PRs welcome), and some endpoints require paid account - but that's the best we can afford to provide" - I would've felt very differently about them.

Sir_Cmpwn 8y ago
Except they did invest the time. They have a bridge software, but it's proprietary and locked out for free users.
- drdaeman 8y ago
  Actually, you're right, I have missed that bridge is a full-fledged IMAP implementation. My mistake.
  - zaarn 8y ago
    Notable here is that the bridge runs on the users computer so they don't have to decrypt mails on their side. IMAP doesn't have a builtin way to deal with fully encrypted mail transmission including all headers and the GPG user experience is last I checked still subpar while additionally I'm fairly certain it doesn't handle fully encrypted mail.
bartbutler 8y ago
We actually have this and have provided it on request. Also, we plan to open-source the bridge, which should alleviate your other concerns.
- drdaeman 8y ago
  Why on request but not public? Why plan but not have it so from the beginning? In my opinion, it's the intent of true openness (even if there are no guarantees of stability or availability) is what matters, not the promise of eventual availability.
  - bartbutler 8y ago
    The API docs are available on request mostly because we are phasing out some old APIs we don't want people to use and don't have bandwidth to provide support for them. The bridge and the import/export tool are not yet open source for similar reasons 1) They are both bandwidth intensive, so we'd like to release access to them gradually 2) Part of running a freemium service is giving paid users perks, and one of those is access to closed betas before general release.
    - drdaeman 8y ago
      > because we are phasing out some old APIs we don't want people to use I still don't see how having API spec with a big fat "everything will break tomorrow, look completely different and may eat your pet hamster - you have been warned" disclaimer is an issue. Existence of a specification doesn't mean that things will be supported forever and are not subject for changes. What matters is that feeling that there's a spec and willingness to publish it - so when it'll be necessary it most likely will be there. If you even plan deprecations ahead and not just refactor things as development goes then I really don't see what could be wrong, because if that's the case - I believe you're better than a lot of in-house APIs I've seen. And if you wouldn't have mentioned that you provide spec on request I wouldn't have thought you have it, and if go with RE. The difference I see is that with open development is so I can persuade myself that when necessity arises I can be sure, having a proper paid account, I can take whatever docs and code is available and help myself. Even though it's recognizably hard it still gives a feeling of safety and control (which IMHO really matters for personal email) - not having to wait for company to eventually possibly release something that may or may not exactly do what I want to have. Developers are, hopefully, sane enough to understand that if there's a warning that things are under development and change then it means that their code will break. And non-developers won't see the difference anyway. > release access to them Access is completely different from source code availability, isn't it? Your APIs do account plan checks anyway, don't they?

Sir_Cmpwn 8y ago

Except they did invest the time. They have a bridge software, but it's proprietary and locked out for free users.

drdaeman 8y ago
Actually, you're right, I have missed that bridge is a full-fledged IMAP implementation. My mistake.
- zaarn 8y ago
  Notable here is that the bridge runs on the users computer so they don't have to decrypt mails on their side. IMAP doesn't have a builtin way to deal with fully encrypted mail transmission including all headers and the GPG user experience is last I checked still subpar while additionally I'm fairly certain it doesn't handle fully encrypted mail.

bartbutler 8y ago

We actually have this and have provided it on request. Also, we plan to open-source the bridge, which should alleviate your other concerns.

drdaeman 8y ago
Why on request but not public? Why plan but not have it so from the beginning? In my opinion, it's the intent of true openness (even if there are no guarantees of stability or availability) is what matters, not the promise of eventual availability.
- bartbutler 8y ago
  The API docs are available on request mostly because we are phasing out some old APIs we don't want people to use and don't have bandwidth to provide support for them. The bridge and the import/export tool are not yet open source for similar reasons 1) They are both bandwidth intensive, so we'd like to release access to them gradually 2) Part of running a freemium service is giving paid users perks, and one of those is access to closed betas before general release.
  - drdaeman 8y ago
    > because we are phasing out some old APIs we don't want people to use I still don't see how having API spec with a big fat "everything will break tomorrow, look completely different and may eat your pet hamster - you have been warned" disclaimer is an issue. Existence of a specification doesn't mean that things will be supported forever and are not subject for changes. What matters is that feeling that there's a spec and willingness to publish it - so when it'll be necessary it most likely will be there. If you even plan deprecations ahead and not just refactor things as development goes then I really don't see what could be wrong, because if that's the case - I believe you're better than a lot of in-house APIs I've seen. And if you wouldn't have mentioned that you provide spec on request I wouldn't have thought you have it, and if go with RE. The difference I see is that with open development is so I can persuade myself that when necessity arises I can be sure, having a proper paid account, I can take whatever docs and code is available and help myself. Even though it's recognizably hard it still gives a feeling of safety and control (which IMHO really matters for personal email) - not having to wait for company to eventually possibly release something that may or may not exactly do what I want to have. Developers are, hopefully, sane enough to understand that if there's a warning that things are under development and change then it means that their code will break. And non-developers won't see the difference anyway. > release access to them Access is completely different from source code availability, isn't it? Your APIs do account plan checks anyway, don't they?