[ecksor]

Correct, each object is on a separate timeline for purposes of operational transform. If both clients are connected at the time the changes are made, then it shouldnt be possible to see the second change before the first. We keep an ordered history of all changes to all objects, though for efficiency, if a client that wasn't present when changes were initially made syncs, changes to multiple objects may appear in a different order. For example, a modification to object A, then object B, then object A again, would appear in the correct order for all clients when those changes are made. If a different client then syncs and asks for what's changed, we may group the two changes to object A such that there would appear to be two changes, a change to B then a change to A.

There is currently limited support for keeping a subset of data synchronized (we have plans to improve this) - if you're using the client libraries in an app, we've focused on supporting the common case of keeping all the data per bucket for a user synced. In the case of keeping all data mirrored to a backend, we provide an endpoint per bucket that you can listen to all changes for all users so you can keep the entire data store synchronized.

[saurik]

Ok, with those semantics (and I think I understand the basis implementations that would cause them), do you perform the "resync" step (which has the property that you can at least get the catch-up changes in a single bulk and hopefully fast download for the entire bucket, even with the internal reordering that happened over time) as a single transaction (by locking the persistant store coordinator); and if not, why?

With keeping the objects on separate timelines, do you or can you run into any problems with CoreData inverse relationships? I'd be concerned that my objects would have issues where a change got synced for object A that had it linking to object B, but somehow my application crashed before it got the synchronization for object B sent. I can imagine various reasons why this concern is stupid, including "saurik doesn't understand how CoreData works" (as I only even learned of its existence a couple days ago).

[cloudmike]

There's currently no explicit lock or transaction, but due to the way we're multithreading, multiple changes are propagated back to your context in one shot.

Core Data relationships (including their inverses) that come over the wire can be lazily resolved by Simperium if necessary.