Thanks! All mutable objects have an internal monotonic counter. Currently, whichever counter is highest takes precedence, and any decreasing counter is rejected

Thanks! All mutable objects have an internal monotonic counter. Currently, whichever counter is highest takes precedence, and any decreasing counter is rejected by the server. The "older" (lower counter) copy will receive an error when it tries to push, which will automatically pull in the most recent state. The application can then decide what to do. That being said, contention issues like this require: 1. the same account 2. to be accessing the same object 3. at the same time 4. from multiple computers 5. one (or more) of which goes offline 6. while both are still producing data This is the primary reason why support for concurrent instances of the same account is very experimental. All objects are single-author, so if you don't have that concurrent sign-ons, you have no contention. Conflict resolution will always be an application-level concern. I would like to expose some synchronization primitives (distributed locks, semaphores, etc) for use within accounts, but this is a ways down the road.