brongondwana

We'll look into it! We'd love this to work for our customers.

It's pretty reliable. I'm actually quite amazed that it's been this long and Apple hasn't opened it more widely. We just happened to be in the right room at the right time to get a custom contract with Apple to have a signing key. The underlying tech is in a couple of open source projects.

Of course we're all hoping that clients move to JMAP at some point, where push is first-class citizen and we don't need the very custom hack that Apple uses to receive pushes right now.

I'd be interested in knowing what kind of searches aren't working for you. Rebuilding our search infrastructure is on the roadmap (from the current Xapian to something which is easier to duplicate as tags into the client's local search database as well so online and offline searches don't have as many differences).

On behalf of all of us here, you're welcome!

Sorry to hear you had that experience.

There are a lot of delays and cross-checks built into our process for re-enabling access to your account, because it would be catastrophic to let the wrong person into an account because they claimed to be that person and to have "lost their password". So a "don't give access" failure is generally less costly than a "give access incorrectly" failure.

It sure sucks to be on the wrong side of one of those failures though. If you ever do give us another try, I hope it goes much more smoothly for you.

To respond to both of you above. Setting up two of these at once would have increased both the up-front cost (hardware for something like this is well north of a million USD) and the complexity and associated risks. Yes, it's partly a "people want it for their own reasons and we should offer it if it's viable" and partly a "it's good to have service in multiple jurisdictions and experience with them in advance of any further balkanization of the internet".

Re-launching might be costly, but dropping millions more on a second location and splitting our systems more would hav been much riskier (note: many of our customers with 'fastmail.com' addresses have chosen the EU region, we can't segment MX records at a tighter boundary than domain level).

So we do what we can - when you login with username and password, the password is only sent to your region's server (based on a lookup from the username which MUST be global, so it works regardless of which of our servers you hit). If you send a username which doesn't exist, we distribute you to a random region in the same percentage, so you can't use it as an existence oracle.

Tell the world you're REALLY fat without telling the world ...

Damn, $2000. I wish I'd kept my copy.

Did you use the 'litmus' test suite? I found it very useful when building Fastmail's (perl) WebDAV file server implementation.

There were also a bunch of fun things with quirks around unicode filename handling which made me sad (that was just a matter of testing against a ton of clients).

As for CalDAV and CardDAV - as others have said, JMAP Calendars/Contacts will make building clients a lot easier eventually... but yeah. My implementation of syncing as a client now is to look for sync-collection and fall back to collecting etags to know which URLs to fetch. Either way, sync-collection ALSO gives a set of URLs and then I multi-get those in batches; meaning both the primary and fallback codepath revert to the multi-get (or even individual GETs).

The good news is, you have less time to be annoyed by it

You're welcome! We're all very keen on keeping email open and something that everybody can build their own tools for.

We're working on it. We still use an unholy set of earlier versions of JMAP internally for our contacts and calendars; in particular the caldav_sync code is gnarly - I wrote it over 10 years ago when I knew less about calendars than I do now! It's still using an earlier branch of what became the perl Net::CalDAVTalk library interally, even though our frontend API is an almost-up-to-date version of what will become the JMAP Calendars spec eventually.

The downsides of developing and testing this stuff as we were writing it up!

We've finished rewriting the objectid generation to give smaller sized and more sortable IDs (they're an inverse of nanosecond internaldates now, plus some extra magic on the low bits for IMAP appends to avoid clashes)... which we wanted to speed up and reduce disk usage for the offline mode.

Next up is indeed updating to the latest spec on calendars and contacts. Files might take a bit longer, I really want to do some desktop clients for the files system, we have a really nice files backend at Fastmail which is only accessible via our interface or WebDAV right now.

That's not strictly true. IMAP has two things, UIDs which are mostly static (there's a UIDVALIDITY cache invalidation key to let a client know that UID information has been lost and recalculated); and message numbers.

UIDs don't change, but of course they can be deleted so it's a gappy list, meaning you can request even quite a large looking range of UIDs and get nothing back.

Message numbers change in every session, and also change every time you get an EXPUNGE. They're basically an ordered list without gaps, so you do a memmove at the offset of the EXPUNGE each time you get an expunge.

There are efforts like UIDONLY (RFC9586) to avoid having to keep that mapping at all, and there's OBJECTID (RFC8474) to let you cache a lot more even when UIDs are changed or when messages are moved between folders.

JMAP is only JSON over HTTP because that's what all the libraries support. Any data format which provides hashes and arrays would work fine, over any transport. So you could use CBOR or protocol buffers or whatever, over any channel you like.