Comment by newscracker | Hacker News Reader

Comment by newscracker | Hacker News Reader

JMAP sounded promising several years ago, and it was great to hear it published as a standard. But it seems like it’ll just remain as what Fastmail (the email provider) uses. Maybe the JMAP team is very small and can’t get more people. Maybe Fastmail doesn’t have enough money and/or enough interest to make it easier to use and to evangelize it with major email providers and email client developers.

I don’t see Outlook365 or Gmail (or even Apple for its iCloud email that has a relatively smaller user base) announcing any implementations of JMAP on their services. I don’t see smaller paid email service providers announce support for it. As it stands now, I don’t see a future for JMAP outside of Fastmail.

A popular client like Mozilla Thunderbird still hasn’t started implementing JMAP [1] and one of the reasons is because…the client and server documentation for JMAP haven’t been updated for a few years. [2]

So yeah, JMAP is like IMAP, but not really. We probably need a successor to JMAP that is liked enough to be implemented by email service providers and by email clients.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322991

[2]: https://github.com/jmapio/jmap/issues/323

I have more faith in JMAP's eventual success than you do, but I do agree that it's frustratingly slow. We knew that adoption would be frustrating slow of course, but I do hope that in 3 years' time we'll have a much better story than we have had in the three years since initial standardisation of the core and mail parts.

Certainly once calendars and contacts are done, and hopefully tasks as well, that will make a more complete ecosystem that is even more attractive than just the email component!

My personal take is that JMAP would start being widely used if we had some simple Python/Go bindings to easily manipulate the emails.

My first reaction as I have seen this standard popping up was not "my email will be faster/better", but "I will be able to setup a nice support@mycompany.com" email address and have both email/web integration with it.

If developers start to embrace JMAP for a derivative usage, I think it could drive the adoption.

I think one of the cooler 'derivative' uses is the integration between fastmail and 1password via "masked email".

https://blog.1password.com/making-masked-email-with-jmap/

Hi Bron - love Fastmail and the innovation you leading.

Question: what do you think is the rough timing on Calendar/Sharing/Contacts/Tasks to be ratified? Within the next year, 2-years, etc?

Hi, I am one of the people writing and coding these standards at Fastmail. There are IETF standard drafts for JMAP calendars, contacts and tasks in the works (not just by Fastmail). We aim at publishing them in 2023. You can check the progress in the IETF calext and jmap working groups and we appreciate any input on the mailing lists!

Awesome. Thanks for much for all you and your colleagues do.

Are you all thinking about, or planning to allow plugins?

eg say I wanted to use jmap to implement some of hey's functionality -- for instance the screener that isolates and allows ban of new emails on first contact. Rather than a client, can I have a server that listens to my fastmail inbox and (potentially) moves emails as they're delivered?

Any chance you're thinking about allowing UI space for things like that?

I've had it confirmed by on of the top two mobile OS providers, that their email developers have JMAP on the roadmap.

did they share some ETA?

No :/

> Maybe Fastmail doesn’t have enough money and/or enough interest to make it easier to use and to evangelize it with major email providers and email client developers.

All the other major email providers are selling their own proprietary services or only offering webmail clients.

They have no interest in implementing modern open specifications. They only support things like SMTP and IMAP for legacy reasons.

You are likely right about all of these things. I agree commercial E-mail providers don't currently have a reason to offer JMAP support. Thunderbird already has robust IMAP support so why change it. But JMAP provides a new avenue to E-mail client development that is both easier for existing clients to deal with and encouraging for new development.

> Outlook365 or Gmail

Why would either of these build a bridge over their lock-in moat?

Weird comment considering how both of them already support POP3 and IMAP.

I think the cynical response would be that these a) may have added these protocols before their market dominance when it was of clearer benefit to them, and b) are widely used in business where businesses have certain demands like interoperability.

I think Microsoft is deprecating the use of anything but Outlook.

"to evangelize"

It's sad that superior standards need to be evangelized to even hope to gain traction.

Reply on news.ycombinator.com