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.
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.
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.
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 :)
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...
You can use https://stalw.art. Compared to other email stacks, it is very easy to set up. Its support is on par with Fastmail.
I develop a JMAP email app (https://mailtemi.com) and have run equal tests against stalw.art locally as well as Fastmail.
As a server (https://stalw.art/) has very solid JMAP support.
James (https://james.apache.org) has good support too. Only the filter part of the API lacks some features.
"According to the company's filings, Mitchell Baker's compensation went from $5,591,406 in 2021 [PDF] to $6,903,089 in 2022."
Did not continue to dig further.
Mozilla tanked a lot, even Thunderbird is doing better recently.
So definitely part of the 'parasitic upper class.
Gmail is successful because it naturally is the biggest honeypot. Most antispam API filters are like accumulators. When a trend is detected, the rest are protected. But overall, it's about scale.
Also, after code the CalDAV ↔ JSCalendar part, using only IANA time zones instead of scattered ones in CalDAV components makes things much simpler.