So I'm not sure I see how the data model in the current sync spec helps with syncing data. Also the current spec draft is lacking a transport format as well. I propose using the dual shadow data model described here: https://neil.fraser.name/writing/sync/ ## Data Model: and Transport: Client side each piece of data which is currently in active synchronization (ie the client is sending AND receiving updates at the same time) has a copy of her data which represents the current assumed good synchronized state. She also has the copy of the data she is editing. When she has finished her edit (for an use case specific defined by the developer definition of finish) the system will generate a diff based on the JSON representations of her shadow and her model. The model will replace the shadow and a diff of her data as well as a checksum of her data will be sent to the server for processing. Server side the server will maintain its own model of the shared data, as well as shadows for each session currently sync the data. When it receives a sync, the diff will be applied to the server's shadow of the session which sent the diff. If the diff merges cleanly and the checksum of the server shadow matches the checksum in the transport, then the server will update the canonical model of the data against what was in the session's updated shadow. The server will then diff all of its sessions' shadows against its model and send out diff messages to the clients. I've made a spreadsheet* where I follow one of QMX's sample applications and step through a few workflows with my proposed data model. (This is the data model I use in the DevNexus sync demo and the real time text demo). I would welcome someone to implement the use case with QMX's proposed data model. * https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3... wdyt? Who would mind doing the data flow for the other model?