If you look at the sync directory in the Chromium source code, you can find all of the proto files in the protocol subdirectory. If you want to see how the XMPP-based event notification protocol works, you might want to take a look at the sync listener tool included in the source code, which can log into Google’s XMPP server and echo sync notifications at the command line.
The use of an open protobuf format and standards-based XMPP means that it should theoretically be possible for a third-party to create a client application that is interoperable with Chrome’s synchronization service. Of course, doing so in practice would still be a technically challenging undertaking.
The mechanics are complicated and there is no high-level documentation that describes Chrome’s synchronization architecture. The comments in the source code are instructive and relatively thorough, but they tend to provide a bottom-up view that is—as you would expect of code comments—aimed more at articulating information that is relevant to Chrome contributors.
One of the downsides of Chrome’s sophisticated synchronization protocol is that it’s largely overkill for developers who want to make simple clients, like mobile applications that provide convenient read-only access to the user’s bookmarks in the cloud. The user’s bookmark data is exposed through Google Docs, but it’s not accessible through the GData APIs. There were experimental REST APIs available at one point—which led to the development of some useful third-party client applications like SyncdMarks—but it has since been shut down. Google is expected to offer REST APIs for bookmarks again at some point in the future, but it’s not clear when it will happen.