In the Qbix Platform (
http://platform.qbix.com) the default type of data is a Stream. A Stream is published by a User and one or more Users can be Invited and Participate. Streams are supposed be of different "types" and support posting Messages of different types. The multicasting of messages to participants who are online via sockets is handled by the pltform. Participants who are offline can maintain Subcriptions and receive offline Notifications to their native app on a device (iOS, Android, Mac) or email or sms or facebook. In addition there is Access control which specifies access to the Public as well as individual users and by Labels (like roles, but labels on contacts of the publishng User). Users can be either people or organizations.
The whole thing is supposed to "just work" and, at version 0.8, it pretty much does, stably. But we still have a lot to do.
The reason we chose this is because it supports everything from updating your status / location / whatever to chatrooms and collaborative documents. A chess game is just a stream of type "Chess/game" which supports messages like "Chess/move" and "Chess/resign".
All the developer has to do is implement their stream type, or "tools" (components) to interact with the stream or "preview" it in listings. We provide typical tools such as "Streams/related" which automatically handles showing streams related to some given stream, and can update in realtime, allow creation of more streams, etc. The developer would jst handle incoming messages and process their effects. Also sometimes a stream might Refresh because the user, say, came back to a mobile app after it was suspended in the background. In this case the stream player or preview gets the latest state instead of "replaying" what would potentially be 100s of messages. And the whole page doesnt need to be reloaded. It all works already.
Now we are working on Offline streams. For example, a stream that has been created offline isn't shared with anyone so no one else can write to it. This means we ca handle all the persistence on the client and sync it later, when the client connects.
We do not attempt to solve issues via "heuristic" diff based sync algorithms. Instead, the source of truth is the Publishing User's server and it is also the source of chronological order of the messages. The developer never has to worry about messages arriving out of order, or something else, just use the JS API. In addition, we handle the CAP theorem by requiring consistency only per stream. If one message contains (hashed) info from another message on some other strean, we know it was posted later (like bitcoin).
In the end we plan to make this platform completely distributed and power social layer for the web like wordpress powers blogs.
So that's how wedo it!