(Long email, but please read, we need to make decisions to enable Bidirectional Bookmark Sync in Firefox for iOS)
BACKGROUND We have landed bidirectional bookmark sync in Firefox for iOS. This lets people sync their bookmarks both ways. Changes you make on your iOS device will go to the cloud where other devices can pick it up. Changes pushed to the cloud by other devices will appear on your iOS device. This feature is currently not fully enabled. Instead, we shipped 3.0 with bidirectional bookmark sync running in read-only mode. We show all your bookmarks that we took from the cloud but you cannot change them. This is pretty much the same thing we have been shipping in previous releases. Users will not notice any difference or anything new. The reason we decided to disable the bidirectional sync code is as follows: The iOS sync client is currently the most correct sync client we have. But part of that is that the code expects the cloud to contain correctly formed bookmark data. Simplified example: a bookmark must have a unique id and must have a correct parent folder. And the parent folder must know about the items in it. If there are inconsistencies in that structure then the bookmarks we take from the cloud cannot be merged in the iOS database and the bookmark code automatically falls back to a read-only mode. Inconsistent data happens because our other products that are part of the sync eco-system are not perfect. Because of design decisions that go back many years or simply due to bugs or incomplete implementations, our other sync-enabled products, the server-side included, can cause your bookmark data in the cloud to get in a bad state. As a user you don’t have to do anything specifically bad. It just happens. When your bookmark data in the cloud is in a bad state, iOS gives up. Other clients like Desktop and Android try to make the best of the situation, but the results of that varies greatly. Sometimes you will not see bookmarks that should be there. Or your folders get re-organized. Or things get dumped in Unsorted. Sometimes things are merged in some way and then synced back to the cloud which results in even more data loss in your other devices. We have seen complaints and bugs about this behavior for many years. Some early metrics show that it is very likely that at least 50% of our (iOS) users will have this problem. If we look beyond iOS, the percentage may be higher. These people thus cannot reliably use bidirectional bookmark sync on iOS. THE GOOD A number of the underlying problems have been identified and as a result a number of bugs have been filed to improve the situation on desktop, android and the server-side to improve sync data quality. These fixes are not just good for iOS, this is good for the complete sync ecosystem. This is not an iOS specific problem. It happens everywhere, we have just ignored it for a very long time since things seemed to work. Everyone will benefit from this. The quality of sync services will improve in general, for all products. Which is something we all want. On iOS we can detect if someone’s data is bad. And we use telemetry (on our TestFlight builds) to collect this. So iOS is currently the canary. We can look at our telemetry and we can monitor sync data quality. This means that we have great insight and we can actually see if changes we make in other places will result in the data quality improvements that we are looking for. There is also a recovery mechanism. You can reset your synced data via Desktop. (And maybe Android?) You can tell it to replace your data in the cloud with the current copy you have in Desktop. This will fix things. Sometimes permanently. Sometimes temporary until you hit behavior or bugs that causes bad data again. Nevertheless, this is an escape hatch. THE BAD The problem is, and this is what this discussion is really about, it may take a while before changes to the other participants in the sync ecosystem are landed and in user’s hands. Things can be unpredictable. Even if your data is good now, it can get in a bad state when you use Firefox on another device. SO … The core of this discussion is this: for iOS we don’t want to wait to roll out this feature. We have our code ready and it is a highly requested feature. So, what I want to discuss is some options on how we can enable bidirectional bookmark sync on iOS. The options below are a discussion starter. Lets talk about it and see what we can do. OPTIONS Keep the following in mind: * Bookmark Sync may work or not for an idividual user. * After initially downloading your bookmark data on an iOS device we will actually know if it is in a good shape or not. * If the data is not in a good shape, your bookmarks will appear in fallback, read-only, mode. * Even if the initial download looks good, your data may get inconsistent at some later stage at which point the bookmarks will become read-only. Options that require little or no code: 1. Just enable it We know it will not work for everyone. But with the right messaging we can tell people this is experimental or may not always work. We can also add feedback in the application to explain to people why their bookmarks are read-only. We can provide instructions (SUMO article) on how to re-upload your sync data with Desktop. 2. Let users enable it Building on option 1, we create an option in Settings to ‘Enable experimental bookmark sync’. It defaults to off. People can decide if they want to participate or not. We can message this as experimental or beta or just explain what the result can be. We can provide instructions (SUMO article) on how to re-upload your sync data with Desktop. 3. We automatically enable it when we discover your data is in good shape After we do the initial bookmark sync, we actually know if your data is bad or not. If it is good then we can enable bi-directional bookmark sync. If it is bad then we fall back to read-only. However, since data can also become corrupt at a later time, we still need to deal with that. But, we can explain to the user why this happened. We can provide instructions (SUMO article) on how to re-upload your sync data with Desktop. 4. Need more options! TOPPINGS Things we can do on top of all the options above: 1. We can make the iOS client more lenient There are some cases where the iOS client can ignore certain cases of bad data. It is not a solution, but this could make the success rate higher. 2. We make the iOS client self-healing If we detect data inconsistencies we may be able to fix them, and then give the user to re-upload their data back the server. Lots of complexity here. What do you think? What is a good path forward. Speaking for the iOS team, S. _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
