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.
It's designed well, from the ground up with a lot of lessons learned from some pretty serious email junkies. Anyone hemming and hawing about JSON being selected as the transport encoding or whatever is just raising silly points. You could do JMAP over protobuf too probably if you cared, but the whole point (IMO) is to get the hell away from unstructured protocols.
oh i mean i rant about it too but its like, a byproduct of the real goal, and since most clients are running some type of webapp it makes sense. you could definitely use something like messagepack or protobuf if you had an extension that negotiates it.
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.
I'm not defending it at all, but I think it's worth pointing out this pay rate is below the rate most CEOs of tech companies of this size are making. I don't really know what the solution here is but I imagine any CEO they replace her with would also seek a high salary. I'd love for them to become a worker-owned cooperative like Igalia but I really don't see that happening any time soon
I don't agree with Mozilla paying that huge CEO salary, but…
Do you know Firefox's handy new offline translation feature? That's AI a well. And Firefox is the only browser that doesn't leak your web page when translating it.
There are plenty of other uses for AI, such as describing images without alt-text for the blind, or summarization. I, for one, want AI in my browser, you can't really say that “nobody wants it”, when many people clearly do.
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.
Yeah. Progressive web apps are a great way to hedge bets on this. They also bypass App Store censorship, binary tampering, etc.
Maybe someone will revive firefox os or build a better successor to it.
Ideally, there’d be a law saying that any government service (direct, or contracted out, so including infrastructure like parking and EV charging) must be offered via a PWA that works in EurOS, iOS and Android.
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 :)
Yeah for high-end phones with lots of storage, fully offline full text search would be really nice.
Often I know that some email with a substring exists and I search for it in Mail app, and it goes off to do a server search… And when you need it most, you probably have 1 bar of range, or have no cell service and no available WiFi. Example: pulling up reservation details while traveling in a foreign country.
Or even worse, sometimes I look at some email in Mail and it’s there, and then hours later, while on bad network conditions, I look at it again and see “This email has not been fetched from the server. Download?”, which then just hangs.
I have a 1TB iPhone and a 2TB iPad. My main Gmail account is not large by any means - ~50k emails and 5GB space. Even though I have all this space on my iPhone/ipad available and willing to commit a bunch of it to email with all attachments and full text index, there seems to be no way to do it.
The Gmail app has a slider for “days of mail to sync”, but the max is 90 days, and not “All time” like one would expect. Anyways, good luck with Mailtemi!
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.
It may use less sockets but that doesn't necessarily mean less resources. Parsing JSON is expensive, especially when there are binary types interleaved in it.
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.
Nah, JMAP is optimized to make fewer and cheaper calls to the server. I agree that it was a mistake to use JSON for JMAP but I doubt the overhead of using JSON matters in practice compare to the benefits. Parsibg JSON with SIMD instructions is very cheap.
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...
No doubt JMAP is superior for the problem it solves. I wonder if it will matter in the end though. I have the impression MS is positioning it self to be the only viable AI platform where mail and calendars are just a tiny part of that. So while not really competing in the same domain it may be that both IMAP and JMAP may feel as relevant to the world as IRC or XMPP in the not too distant future.
Sure, and we're the vocal (?) minority here. The SOHO/corporate/family world will uncritically use whatever shit MS regurgitates for them for all the usual reasons.
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.
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.
Also, after code the CalDAV ↔ JSCalendar part, using only IANA time zones instead of scattered ones in CalDAV components makes things much simpler.