[go: nahoru, domu]
Open Bug 1322991 Opened 8 years ago Updated 11 days ago

Add support for new JMAP protocol

Categories

(MailNews Core :: Networking, enhancement)

Product:
MailNews Core
Component:
Networking
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: tanstaafl, Unassigned)

References

(
URL
)

Details

(Whiteboard: https://jmap.io/client.html http://jmap.io/) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726

Steps to reproduce:

Learned about the existence of the new JMAP protocol.

Also learned that the Dovecot author is working on adding support for it in 2.3 (current version is 2.2.27, so 2.3 can't be all that far away):

http://www.dovecot.org/list/dovecot-news/2016-March/000313.html

So, it (the new JMAP protocol) has legs.


Actual results:

Checked, didn't find an open bug/enhancement request for Thunderbird to add support for it, so here I am.
Severity: normal → enhancement
OS: Unspecified → All
Hardware: Unspecified → All
URL: http://jmap.io/
One issue here has been that JMAP is supposedly internally implemented at Fastmail, but they have not actually exposed the protocol fully yet to their actual accounts. There is a bit of a chicken and egg problem here, but it would be hard to develop the protocol without a working target.

In anyone knows of an actual working target that would be good to hear about.
The question was just asked on 11/27, and Aki confirmed it is still targetd (but no firm commitment) for 2.3.

I just asked if there is a git branch that someone can follow the WIP, will respond again if/when I get an answer.
(In reply to Kent James (:rkent) from comment #1)
> One issue here has been that JMAP is supposedly internally implemented at
> Fastmail, but they have not actually exposed the protocol fully yet to their
> actual accounts. There is a bit of a chicken and egg problem here, but it
> would be hard to develop the protocol without a working target.
> 
> In anyone knows of an actual working target that would be good to hear about.

Maybe someone knows someone at Fastmail and can ask them if they could expose a test account with full support for their JMAP implementation that TB devs could use for testing?
(In reply to Charles from comment #2)
> The question was just asked on 11/27, and Aki confirmed it is still targetd
> (but no firm commitment) for 2.3.
> 
> I just asked if there is a git branch that someone can follow the WIP, will
> respond again if/when I get an answer.

Aki responded that they don't have anything available for beta testing yet, but hopefully will early next year...
There are more complete implementations than Dovecot, and so far the most complete one is the JMAP Proxy by Fastmail, placeable in front of an IMAP/CalDAV/CardDAV support and produces JMAP output, and currently supports the full specification. 

Fastmail are also working towards enabling JMAP support, so this may likely happen before Dovecot hits 2.3, and Cyrus is more likely to gain a full implementation as it is already a WIP before Dovecot does.

I'd really recommend talking a look at this thread where all things JMAP are discussed:
https://groups.google.com/forum/#!forum/jmap-discuss
Excellent, thanks.

Does Fastmail offer a way for clients to test against their implementation? If not, maybe they would make an exception for Thunderbird.

Although that would of course require someone to actually be working on the implementation.

And thanks for the link to the discussion group.
My pleasure. 

I don't believe they do, currently - but they have said they are actively working on getting JMAP support enabled, and in the meantime the next best thing is the Proxy. 

I don't think it's a case of 'making an exception' but that they are still trying to get JMAP fully into production - if they did, it would be in their best interest to enable access for all, of course (to enable client-side testing etc). 

Your best bet is to reach out to Bron Gondwana at Fastmail (brong@fastmail.com) and I'm sure he will be able to update you with more details.

Perhaps you could even ask them if they would consider part/fully funding the work of a developer to enable JMAP, they very may well say yes and if you don't ask, you don't get. It is their interest for JMAP to take off, and they are doing a great job into getting into the main servers, but the client-side implementations are a bit behind, with the guys at Kolab taking their sweet time with Roundcube Next. Atmail however are working on a mobile app with JMAP support, and Kolab/KDE have said they will put JMAP into Kube after they have finished with IMAP/CardDAV/CalDAV support, but that is of course a while away.
In https://dovecot.org/list/dovecot/2016-December/106553.html Brong writes "We are actually pretty close to a complete implementation in Cyrus now, and there's the proxy of course.  We'll be doing a release candidate of Cyrus 3.0 with JMAP support on January 13th."

Note, k9mail has listed jmap as a GSOC2017 idea https://github.com/k9mail/k-9/wiki/Google-Summer-of-Code-2017
Status: UNCONFIRMED → NEW
Ever confirmed: true
URL: http://jmap.io/ → https://tools.ietf.org/html/draft-jen...
Whiteboard: http://jmap.io/
(In reply to Wayne Mery (:wsmwk) from comment #8)
> In https://dovecot.org/list/dovecot/2016-December/106553.html Brong writes
> "We are actually pretty close to a complete implementation in Cyrus now, and
> there's the proxy of course.  We'll be doing a release candidate of Cyrus
> 3.0 with JMAP support on January 13th."

doesn't appear to have happened, unless I missed something

 
> Note, k9mail has listed jmap as a GSOC2017 idea
> https://github.com/k9mail/k-9/wiki/Google-Summer-of-Code-2017

looks like nothing came of that.

A tb-planning thread from 2015 https://groups.google.com/d/msg/tb-planning/qHxi9KqIoU8/N5sNHnylDAAJ

Other latest info 
- https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/
- https://github.com/linagora/jmap-client  (code)
- https://blog.fastmail.com/2017/12/08/fastmail-at-ietf/
See Also: → 288514
Cyrus 3.0 had limited JMAP support (old drafts) - cyrus master has the most current draft on it, and I expect we'll cut a 3.1.x pre-release version with that pretty soon.

The JMAP proxy (https://github.com/jmapio/jmap-perl) is also close to current draft.  There are a couple of small holes, but it's been ported to the new style objects and we're preparing it for testing at the Hackathon in London.

https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon

Obviously if there's anything from Thunderbird, or anybody from Thunderbird will be around and can join us in London, we'd love to see you!
Cyrus 3.1.4 just go released with up-to-date (for now!) JMAP support :)  We're starting to deploy testing infrastructure on top of that at FastMail too.
There is a lot of activity around JMAP. What would be the current status or future plans for this support in Thunderbird?
How would a JMAP-compliant release of Thunderbird choose a protocol to communicate as client with a server offering a full choice of JMAP, IMAP, and SMTP?

IMAP with IDLE results in mostly simultaneous updates to various connected devices as the ones showed in the movie at https://jmap.io/.  Speed obviously depends on implementations.  The "Reinventing IMAP" article, https://lwn.net/Articles/680057/, mentions contacts database and calendaring as the relevant advantages of JMAP over IMAP4.  So bug #86405 and bugs about Lightning calendar synchronization would be involved too.

Just mumbling...
Thanks Tylera,

Definitely a good time to be looking at adding JMAP support again, given that the protocol is now unlikely to have more changes.

Regards,

Bron.

I'd very much like to see some action on this, JMAP would really push Thunderbird ahead of many other clients.

Looks like it might be picking up in other clients, K9 recently announced they would be doing it.

I think if Thunderbird supported it, there would be more motivation for it server side. I'm hoping Dovecot and Open-Xchange do this soon.

Whiteboard: http://jmap.io/ → https://jmap.io/client.html http://jmap.io/

(In reply to Daniel Gray from comment #18)

I think if Thunderbird supported it, there would be more motivation for it server side. I'm hoping Dovecot and Open-Xchange do this soon.

Definitely agree.

There's also the new RFC - 8887 (https://tools.ietf.org/html/rfc8887) which describes JMAP over Websocket.

I don't view this as a chicken and egg problem. As one of the most widely used email clients, Thunderbird implementing JMAP would go a long way in accelerating adoption of JMAP in my opinion.

There is a GPLv3-licensed Rust implementation of JMAP at https://git.meli.delivery/meli/meli/src/branch/master/melib/src/backends/jmap
Maybe it can be used by Thunderbird?

I don't know since when, but an official guide for client developers has been published: https://jmap.io/client.html

On the official website it also says the following components have been finished:

  • The core protocol [RFC 8620]
  • JMAP Mail [RFC 8621]
  • A JMAP Subprotocol for WebSocket [RFC8887]

uh, the guide could be outdated though! see https://github.com/jmapio/jmap/issues/323
my bad.

(In reply to Lars Tobias Skjong-Børsting from comment #20)

There is a GPLv3-licensed Rust implementation of JMAP at https://git.meli.delivery/meli/meli/src/branch/master/melib/src/backends/jmap
Maybe it can be used by Thunderbird?

Hi all, I'm the writer of said implementation. There was some effort at the start of 2022 to separate this code into a standalone library. The code itself is structured so that it gives you the way to define the various JMAP objects (Requests, errors, emails, etc) in Rust structs and {,de}serialize them from/to json. So theoretically this can be somehow plugged into Thunderbird with an FFI interface I'm willing to provide.

I can't commit to a project of this size however since I work freelancing and my availability is fluid. I am open to being sponsored/contracted in order to do this as part of my job.

Severity: normal → S3

https://connect.mozilla.org/t5/ideas/jmap-support-or-similar-for-thunderbird/idi-p/28974

Get a jump on these other systems and show the flexibility of OSS.

Ok, its been 7 long years since I first opened this enhancement request, and a lot has happened...

Currently, there is a fully functional open source JMAP/IMAP server implementation written in Rust called Stalwart:

https://www.stalw.art/

They have also released a fully functional Client Library, also written in Rust:

https://github.com/stalwartlabs/jmap-client

So, maybe one of Thunderbirds fine Devs could take a look and see if this is something that could maybe jumpstart adding JMAP support into Thunderbird?

To piggyback on what Charles posted recently ...

I've been following the Stalwart Labs implementations of the JMAP client library and server daemon in Rust for some time. The project continues to look promising. I'm finally getting around to attempting a switch-over to Stalwart's server and would be happy to help test any attempt to implement their client library.

You need to log in before you can comment on or make changes to this bug.