6 ms·

Any IMAP over REST API should just implement JMAP (RFC 8620 and 8621).

by dochtman 7y ago

rakoo 7y ago
Indeed. Which is the perfect occasion to ask: who besides Fastmail implements it ?
- brongondwana 7y ago
  Right now - not heaps. https://jmap.io/software.html https://jmap.io/software.html has a list of some known implementations.
  - detaro 7y ago
    https://github.com/jmapio/jmap-perl https://github.com/jmapio/jmap-perl seems the most similar to the project discussed here. Anyone have experience with it?
    - brongondwana 7y ago
      It was largely written in about a week, a few years ago. It's quite stale now unfortunately. It was updated to the current RFCs for mail, but it's still on a very old Calendars version. The downside of the JMAP model for a proxy to IMAP is that you do need to have a bit of state in your proxy server. jmap-perl uses a sqlite3 database per user for storing that state. Structurally, it's a non-blocking server in front of a forking server - the non-blocking handles connections and event streaming, and opens multiple backend forking servers per user, one for reads, one for writes, and one for background syncing/import.
andris9 7y ago
There is only a handful of IMAP server implementations and there are going to be even fever JMAP servers. It is super bloated, the RFCs 8620 and 8621 are already 200 pages in total. Not an easy thing to integrate with.
- brongondwana 7y ago
  To be fair, RFC3501 is 108 pages, and the bis (draft-ietf-extra-imap4rev2-12) is 157 pages. It's a complex problem space. I'm looking forward to getting JMAP Calendars and JMAP Contacts done, at which point is becomes a much more compelling replacement for multiple protocols.
  - toomuchtodo 7y ago
    Anything we can do to help in getting those other extensions done?
    - brongondwana 7y ago
      The next IETF meeting is in Vancouver in late March - we'll be discussing them there. Other than that, get involved on the mailing list, and help review the documents! https://datatracker.ietf.org/group/jmap/meetings/ https://datatracker.ietf.org/group/jmap/meetings/ https://www.ietf.org/mailman/listinfo/jmap https://www.ietf.org/mailman/listinfo/jmap https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/
  - deleted 7y ago
    [deleted]
- inputmice 7y ago
  The problem JMAP is addressing is quite complex that’s why the JMAP spec is long. I do not however find it to be bloated. On the contrary I actually found it quite easy to read. (I've implemented jmap-mail on the client side.) One could potentially write JMAP as a proxy to an existing IMAP server (just like your 'imap-api') therefore the current lack of JMAP servers doesn’t really matter.
  - andris9 7y ago
    It is easier on the client side as you’d only have to implement the parts you actually need. In server side if you want to expose JMAP then you’d have implement _everything_. You can’t decide for example that as no-one actually copies messages but moves, then you’d skip the copy endpoint.

Any IMAP over REST API should just implement JMAP (RFC 8620 and 8621).

rakoo 7y ago

Indeed. Which is the perfect occasion to ask: who besides Fastmail implements it ?

brongondwana 7y ago
Right now - not heaps. https://jmap.io/software.html https://jmap.io/software.html has a list of some known implementations.
- detaro 7y ago
  https://github.com/jmapio/jmap-perl https://github.com/jmapio/jmap-perl seems the most similar to the project discussed here. Anyone have experience with it?
  - brongondwana 7y ago
    It was largely written in about a week, a few years ago. It's quite stale now unfortunately. It was updated to the current RFCs for mail, but it's still on a very old Calendars version. The downside of the JMAP model for a proxy to IMAP is that you do need to have a bit of state in your proxy server. jmap-perl uses a sqlite3 database per user for storing that state. Structurally, it's a non-blocking server in front of a forking server - the non-blocking handles connections and event streaming, and opens multiple backend forking servers per user, one for reads, one for writes, and one for background syncing/import.

andris9 7y ago

There is only a handful of IMAP server implementations and there are going to be even fever JMAP servers. It is super bloated, the RFCs 8620 and 8621 are already 200 pages in total. Not an easy thing to integrate with.

brongondwana 7y ago
To be fair, RFC3501 is 108 pages, and the bis (draft-ietf-extra-imap4rev2-12) is 157 pages. It's a complex problem space. I'm looking forward to getting JMAP Calendars and JMAP Contacts done, at which point is becomes a much more compelling replacement for multiple protocols.
- toomuchtodo 7y ago
  Anything we can do to help in getting those other extensions done?
  - brongondwana 7y ago
    The next IETF meeting is in Vancouver in late March - we'll be discussing them there. Other than that, get involved on the mailing list, and help review the documents! https://datatracker.ietf.org/group/jmap/meetings/ https://datatracker.ietf.org/group/jmap/meetings/ https://www.ietf.org/mailman/listinfo/jmap https://www.ietf.org/mailman/listinfo/jmap https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/
- deleted 7y ago
  [deleted]
inputmice 7y ago
The problem JMAP is addressing is quite complex that’s why the JMAP spec is long. I do not however find it to be bloated. On the contrary I actually found it quite easy to read. (I've implemented jmap-mail on the client side.) One could potentially write JMAP as a proxy to an existing IMAP server (just like your 'imap-api') therefore the current lack of JMAP servers doesn’t really matter.
- andris9 7y ago
  It is easier on the client side as you’d only have to implement the parts you actually need. In server side if you want to expose JMAP then you’d have implement _everything_. You can’t decide for example that as no-one actually copies messages but moves, then you’d skip the copy endpoint.