Well, there's more than just the database. So far we've discussed the current effort to get 100% of Citadel's persistent storage into the database. We've already moved citadel.config and citadel.control, along with user profiles (bios), user photos (userpic), netconfigs, etc. We should have 100% coverage there in the not too distant future.
Also remember, however, that there is another layer of our data model, and that is the server's current working state. Multiple master servers would break up the list of online users into little islands, for example. Each server would also be trying to work through the outbound SMTP queue, resulting in people getting multiple copies of email messages followed by conflicting database commits.
Long story short, I don't see master/master in Citadel Server's future. It simply does way more than Dovecot. Master/slave is far more likely, though. If a Citadel Server is launched in slave mode, it simply receives database updates and does nothing else. Then if it needs to be promoted to a master it relaunches in the normal mode.
This is a great technical discussion though, and I do enjoy talking about it. It should be clear though, that we are sort of blue-skying here. Right now I am focused on the following:
1. WebCit modernization (follow the "webcit-ng" branch if interested).
2. Simplifying the server footprint and removing obsolete functionality. The database consolidation effort is part of this. The removal of things like federated domains is another. The idea here is that we want to remove the things that cause 90% of the support issues reported in the Citadel Support room. (Yes, I know, when we do this we will create yet another tier of people who can't read instructions, and this cycle will repeat forever.)
3. Turn ctdlsh into a useful tool that we can actually tell people to use. I'll probably remove system configuration tasks from the text client eventually.
