> IMAP's killer design flaw was that it imposed a strict UID consistency requirement between replica servers if client sync was to work correctly, i.e. you need

> IMAP's killer design flaw was that it imposed a strict UID consistency requirement between replica servers if client sync was to work correctly, i.e. you needed a master-slave setup or Paxos, you couldn't use a true multi-master setup or CRDTs with eventual consistency because of the possibility that clients might miss UIDs. +1, and it's been a while since I've dealt with this, so my memory's fuzzy, but I think it's even worse than that in a couple ways: * The failure mode here is not just that the client misses UIDs but that a given mailbox/uidvalidity/uid means something different to the client than to this replica. Then when the client says to delete one message, they delete a different one. This would be a lot less likely if the server could use a uuid for a message (so collisions are unlikely) instead of following a sequence and/or if it the identifier didn't need to change whenever it moves to another folder. (My memory is even fuzzier here, but iirc in gmail's case, its emulation of the folder model also means a message can have multiple uids at a time, one per label. That mismatch between the folder setup clients expect and the label model is another problem with IMAP. Strictly speaking, I think you can do it all with one folder and an IMAP flag for each label; it's just that the clients don't expect it to work this way.) * Even with a synchronous replication design, there's the possibility that due to a bug or bad machine the server replicas won't match entirely, or just the client state doesn't match. And if you discover and fix such a problem on the server side, your only option for addressing the bad client state is to bump uidvalidity, which is super annoying to the client. It'd be nicer if you could do something that kicks off some softer sync that doesn't use as much bandwidth, lets the client be more usable while it's happening, and/or lets the server know what mismatches were actually found for diagnostic purposes. I haven't looked into JMAP before, but I hope it materially improves this situation...