I had to develop my own synchronization algorithms after doing a lot of research on OT for a couple of reasons. One is that Google sometimes relies on being a c

I had to develop my own synchronization algorithms after doing a lot of research on OT for a couple of reasons. One is that Google sometimes relies on being a centralized authority (Google's server) to resolve some conflicts, especially for collaborative rich text editing (Neil Fraser, a sync genius that Google hired, has a great talk on his own type of implementation "diff-match-patch", although Google uses different algorithms now I believe). Another is that OT sometimes requires you writing your own transformation commands, and I wanted something that was generally applicable to most data types without forcing developers to write their own. (It has been a while since I did a lot of this reading, so this comment may not necessarily be accurate/true, please somebody correct me!) Instead, I developed my own method, called "Analytical Fluctuation" - but I haven't written papers on it yet, but need to soon! One requirement is that it has to be truly peer to peer and cannot rely (even occasionally) on some centralized server or leader election setup. Another requirement is that it has to be latent proof, which for me means "preparing for the future" when people need to collaborate on documents not only from the other side of the world but also from Mars. This is where Neil Fraser says his system breaks down, because if there is too much latency, the patches stop applying idempotently. Again, more on this in upcoming posts.