I once used a similar trick -- queuing uncomfirmed outgoing edits, and replaying them on top of incoming models -- when working on a web client app (Laszlo Cale

I once used a similar trick -- queuing uncomfirmed outgoing edits, and replaying them on top of incoming models -- when working on a web client app (Laszlo Calendar, a browser UI to an iCalendar-backed server). It was an act of desperation: user edits would disappear and reappear, depending on the relative latency of client->server and server->client connections, and trying to add delays was a game of whack-a-mole. Replaying an edit queue onto the incoming model eliminated lots of code and all the bugs. I tried to write something up about this although looking back half a decade later leaves me even less impressed by my communication skills. Nonetheless, in case it's useful to see some coding details, a (pre-Promises, pre-Harmony, 2008) JavaScript sketch of this is here: http://blog.osteele.com/posts/2008/02/synchronizing-client-models http://blog.osteele.com/posts/2008/02/synchronizing-client-m... This was before Operational Transform, but in retrospect it could be viewed as a simplified subset of that algorithm. Several times since I've seen clients that try to skip this, sending the edit upstream and then synching to the model that comes back down, which may not reflect the edits. And then add delays which sometimes hide the problem.