> Not full history as in "you can rewind back in time and see every possible past state", no. If I wanted one of those, I'd probably use git as the substrate.
No, not "history" in the git sense, just "history" in the simpler email sense, i.e. "email history", all past emails in their final converged state.
> but at the point where you're switching between multiple masters in a split brain from your client, all bets are off
CRDTs handle split brain fine. They eventually converge. You just don't want your clients flapping in the meantime by resyncing tons of data. That's where a distributed sync algorithm would help keep things working in the interim.
> Merkle tree would is great for full history - [...] but it's way over-expensive for email.
Does JMAP then not support syncing full history efficiently as a key design priority?
> That would be a pretty massive change to the entire data model of IMAP. It's never going to happen[tm].
Sure, and that's why I had hoped JMAP would, especially in a distributed master setting, since this was something IMAP overlooked.
I guess it's because JMAP still needs to be backwards-compatible with the strict consistency master-slave restriction of IMAP?
> What we use for IMAP replication in Cyrus is much dumber than all this - it uses a per-message CRC and XORs them together for the whole mailbox to create the sync_crc value. If those don't match, it does a resync. Fixes up split brain just fine while being cheap and dumb for the common case.
You're implementing the first layer of an incremental Merkle tree right there. How many bits are those CRCs just out of interest?
> I wrote something about how you fix UID clashes in a split brain while staying within the IMAP data model many years ago...
Thanks for this. It was a good read and promoting UIDs instead of bumping UIDVALIDITY is a great idea.
Surely, it would be even better if IMAP had support for distributed Merkle Tree synchronization, so that clients can sync with different server replicas without the server replicas having to coordinate or promote UIDs at all in the first place?
I don't know of any algorithm other than a Merkle Tree that will do this correctly and simply and efficiently in a distributed setting?
> IMAP is costly to implement in terms of server resources when you're doing true concurrency, high availability
Yes, IMAP requires expensive coordination among multi-master servers to generate UIDs in such a way that won't mess with client synchronization. In other words, IMAP is not a fully distributed design, it assumes a centralized control plane (think Raft or Paxos), i.e. a single central server with many distributed clients, which is a shame for new systems building on CRDTs.
How does JMAP address this achilles heel of IMAP? Merkle tree sync?
Sure, for modern systems "transfer rates of 30 seconds per byte" would also be "a huge signal flare going off instantly" where metrics track basic software-hardware interaction (latency and throughput, not just on/off error rates).
These metrics also need not necessarily by definition take longer to notice gray failures. You can detect a gray failure transfer rate without having to wait 30 seconds. Another example, but a second or two is enough to notice disk latency issues (and retry to a faster disk), which is probably in the same granularity as the window for detecting "Connection refused".
Hetzner South Africa have datacenters in Cape Town and Johannesburg. Their reliability and support is excellent. I am assuming that your services are not limited to cloud VMs and can run on bare metal machines.
Are these cloud services going to be served from newly built 100% Microsoft datacenters or servers colocated with Hetzner South Africa (Cape Town and Joburg)?
No, not "history" in the git sense, just "history" in the simpler email sense, i.e. "email history", all past emails in their final converged state.