I’ve started a W3C community group to discuss potentially standardizing browser sync, both as a way to make the backend more open to user control and to expose an API so that web app developers can make use of the built-in sync mechanism for their own apps’ client-side data.
If you’re interested in joining the discussion there, I’d love to have more members in the Browser Sync Community Group. I also wrote up a blog post, “Open Sync: Your Browser Data in Your Hands” to help explain why I think this is a worthwhile goal.
I’d love to have some discussion of what the API should look like. For instance, people have pointed out that it would be great if browser A could receive an event when browser B pushes some data. It’s also been mentioned that having built-in operational transforms would be very nice, but maybe out of scope.
Any ideas are welcome at this point.
1 Like
For sync of Applications data, BackgroundSync is a recent ServiceWorker-based proposal.
I asked Alex about this and he thinks the two efforts are essentially unrelated. See discussion here.
I read him saying the goals overlap, but the approaches are different (with which I agree); I guessthe fact that the app-data sync being potentially covered by BackgroundSync may not make it the best initial focus for the browser sync effort (which I applaud).
I can’t speak for the rest of the Chrome team (my opinions are my own here). I’m sure Chrome supporting something like this would add a ton of complexity and new challenges for the already overloaded chrome sync team. However I wanted to say that I support this goal.
The web’s unique strength as a platform is interoperability and reliable competition (due to low switching costs for users). Sync is a great counter example to my argument here: https://plus.google.com/+RickByers/posts/Uq4RR9MuLHs (based on Tim Wu’s excellent book “The Master Switch”).
I’ll try to get someone who knows about sync in Chrome to at least comment on this thread.