3 ms·

I have a hard time believing that JMAP is good specifically because it's yet to grow much further than Fastmail. I love that it's open, and I'm a long term happ

I have a hard time believing that JMAP is good specifically because it's yet to grow much further than Fastmail. I love that it's open, and I'm a long term happy paying customer of Fastmail, but as an engineer I'd be skeptical of JMAP. I don't have the expertise to know if JMAP solves the necessary problems, and there are probably not that many engineers who do as deep IMAP/POP knowledge is somewhat rare at this point.

chrismorgan 3y ago
JMAP was initially developed at Fastmail, but it changed shape quite a bit during the standardisation process at IETF, with significant input from multiple other providers. The end result was definitely the better for it. (In the end, RFC 8620 has two authors listed—one from Fastmail, one from Oracle.) JMAP’s good stuff. (Source/bias: I worked on Fastmail’s webmail from 2017–2020.)
- danpalmer 3y ago
  Oh that's really good to know, I didn't realise it had that much outside input. In that case I'd feel a lot more comfortable betting on it.
ocdtrekkie 3y ago
The problem is Gmail. Google is a bad actor who significantly prefers clients have to support a proprietary API, even though JMAP takes all of the proprietary hacks Gmail built and standardizes them. (Things like snoozed emails, labels, etc. cannot be implemented with IMAP, but can with JMAP.) Supporting JMAP would mean clients that have hacky issues syncing things around labels and snoozed emails could just work, without having to use a proprietary Google API to do it. That alone would be a huge benefit to JMAP being not just widely used, but specifically used by Gmail. The problem is Gmail compatibility has been used as a club to beat down competing OS platforms before, and Google has a strong vested interest in requiring clients use their proprietary APIs and features. Building walled gardens is the core way Google extracts value. It's amazing how the people who have the hardest time believing in JMAP all work or have worked for the company that is most strongly vested in it's failure.
- danpalmer 3y ago
  As I said, I'm a long time paying Fastmail user, and working at Google hasn't caused me to rethink that. It's worth remembering that the Gmail API does more than IMAP can, and predates JMAP. I understand how Google would get to this point.
  - ocdtrekkie 3y ago
    I understand how they got to this point, but I hope you understand that fifteen years ago, Google would've lead the charge to make these things a standard, and today they will sit inside their moat behind their castle walls and ensure even the standard someone else built for them doesn't succeed because openness is harmful to their bottom line.
    - danpalmer 3y ago
      I do get your point, but I also wonder if this could be the exception rather than the rule. Google still appears very active in setting web standards and contributing a lot of open technology and standards.
      - ocdtrekkie 3y ago
        I would say that Google is active in setting web standards that help Google, less so setting web standards that help anyone else. Which, for what it's worth, is capitalism, but unregulated monopoly remains a fundamental flaw in the design of capitalism.

chrismorgan 3y ago

JMAP was initially developed at Fastmail, but it changed shape quite a bit during the standardisation process at IETF, with significant input from multiple other providers. The end result was definitely the better for it. (In the end, RFC 8620 has two authors listed—one from Fastmail, one from Oracle.) JMAP’s good stuff. (Source/bias: I worked on Fastmail’s webmail from 2017–2020.)

danpalmer 3y ago
Oh that's really good to know, I didn't realise it had that much outside input. In that case I'd feel a lot more comfortable betting on it.

ocdtrekkie 3y ago

The problem is Gmail. Google is a bad actor who significantly prefers clients have to support a proprietary API, even though JMAP takes all of the proprietary hacks Gmail built and standardizes them. (Things like snoozed emails, labels, etc. cannot be implemented with IMAP, but can with JMAP.) Supporting JMAP would mean clients that have hacky issues syncing things around labels and snoozed emails could just work, without having to use a proprietary Google API to do it. That alone would be a huge benefit to JMAP being not just widely used, but specifically used by Gmail. The problem is Gmail compatibility has been used as a club to beat down competing OS platforms before, and Google has a strong vested interest in requiring clients use their proprietary APIs and features. Building walled gardens is the core way Google extracts value. It's amazing how the people who have the hardest time believing in JMAP all work or have worked for the company that is most strongly vested in it's failure.

danpalmer 3y ago
As I said, I'm a long time paying Fastmail user, and working at Google hasn't caused me to rethink that. It's worth remembering that the Gmail API does more than IMAP can, and predates JMAP. I understand how Google would get to this point.
- ocdtrekkie 3y ago
  I understand how they got to this point, but I hope you understand that fifteen years ago, Google would've lead the charge to make these things a standard, and today they will sit inside their moat behind their castle walls and ensure even the standard someone else built for them doesn't succeed because openness is harmful to their bottom line.
  - danpalmer 3y ago
    I do get your point, but I also wonder if this could be the exception rather than the rule. Google still appears very active in setting web standards and contributing a lot of open technology and standards.
    - ocdtrekkie 3y ago
      I would say that Google is active in setting web standards that help Google, less so setting web standards that help anyone else. Which, for what it's worth, is capitalism, but unregulated monopoly remains a fundamental flaw in the design of capitalism.