Mailtemi

As a JMAP client implementer, there’s a big plus, beside JMAP, in having an integrated server for email, contacts, and files. Some setups take days even for email, so an easy, fast setup saves a lot of time.

Also, after code the CalDAV ↔ JSCalendar part, using only IANA time zones instead of scattered ones in CalDAV components makes things much simpler.

Yep, there's always someone ranting about JSON inefficiencies, which I don't observe at all :)

Can confirm that (implemented JMAP). Deltas and asking for the entire mailbox instead of folder by folder is really good. And as a side effect: 1. Less client-side logic for sync. 2. There are many JSON parsers compared to IMAP, making it way easier to use. For example, in C++, you only need a JSON headers-only library, whereas IMAP is meh—only Linux, or clunky usage. Btw, I made one from scratch (IMAP Parser). 3. Goodies like offloading HTTP to the mobile network stack, which supports TLS 1.3 and offline (background) sync, compared to manually extracting certificates from an IMAP connection to validate against the device keychain. It's just 10x easier.

Really? Fire the Rust Servo team and double the CEO's salary in the same year? Almost the same money.

Mozilla diversifies by increasing the CEO's salary for nothing.

Wiki: In 2020, after returning to the position of CEO, Baker's salary was more than $3 million. In 2021, her salary rose again to more than $5 million, and again to nearly $7 million in 2022.

The new CEO brings computing for AI money bleed that almost no one wants.

What do you mean by JMAP is 'limiting as an API'?

It actually lifts the IMAP protocol to be used by web apps easily.

In addition to Cloud, there is one more thing: Mobile. Banks. Parking lots. Shops. Europe should invest in a Linux phone OS with NFC and unified push notifications.

This is just a step toward offline support. It's not available yet, because Android comes first.

The app is ready for offline use, but I don't want to implement it without 'full text search.' I plan to use SQLite FTS5. My initial tests with search show that offline search is storage-expensive, which could be problematic for mobile devices. So, the edge cases have started to appear. But it's the most requested feature, and the most interesting/challenging to me :)

It does behind CASA!

Can you give an example of expensive binary data parsing?

Having implemented JMAP and IMAP protocols myself, I haven’t encountered a need in either protocol to send binary data to the server for sync/search operations that would require the server to perform expensive parsing.

JMAP offers many improvements, such as a stable messageId for each message and a state mechanism that allows the server to be queried for changes since the last saved state. This avoids the need for numerous IMAP SELECT commands per folder to check the state using CONSTORE/QRESYNC.

If CONSTORE/QRESYNC aren’t supported by the client, it results in very costly chunked queries just to verify if message flags are still the same.

The same applies to SEARCH—if a user has many folders, it requires multiple network hops to SELECT and query each folder. With JMAP, this can be done in a single API call.

Neither Fastmail's JMAP for third-party apps nor Stalw.art supports Contacts/Calendars yet. Fastmail said that it will be enabled once it passes IETF standardization. Stalw.art also mentioned they will add support after the standard is finalized.

JMAP uses fewer resources server-side, and with their scale, it will probably reduce operating costs. But it will depends on how much they will save compared with devel/migration costs.

MSGraph is slower and not as convenient for email compared to JMAP. In addition to requiring more API calls for the same result, MSGraph starts throttling with HTTP 429 responses after several calls, making the initial synchronization much slower than JMAP or even IMAP.

Hopefully, next year there will be JMAP support for Contacts. As RFC drafts, there are already JMAP specifications for Files and Calendar...