Shared Vaults Update Robustness

Pottmi

If I have a vault on Dropbox and I make a change to the the contents, how is the integrity of the vault ensured?

My use case is:
I will be connecting on a work network that blocks access to dropbox. I will be making changes throughout the day, then when I return home at night, presumably my dropbox will sync.

If I am only making changes on one computer this should not be a problem, BUT that is not case:

1) I will be making changes on my phone, in which case they would sync immediate because the phone connects over cell.

2) My wife will be making changes to shared vaults throughout the day.

3) I will have shared vaults that are running in Windows VMs on my Mac. That is, I will have a vault shared between my mac and a VM running on my Mac.

Because of my reliance on 1password I am not willing to experiment to find this out.

I want a definitive answer from Agile Bits that:

A) They have a robust solution that will not corrupt the vault, and

B ) They have a robust solution that will not overwrite another user's changes, and

C) Some type of overview of the technique/library they use to avoid corruption such that I trust their answer to A and B.

rickfillion

Hi @Pottmi,

That's a great question. The quick answer is that it should mostly "just work." Being on a network where Dropbox access is denied is the same to us as being on a device without a net connection, and this is something any good sync system should support.

Let me try to address each point individually:

A) Vault corruption. On Mac and iOS, the vault you have on dropbox is really just a sync conduit. The data in there is a duplication of the data we have in our internal database. Great care is put into our code that imports/exports from/to any sync conduit. Seeing that it's software, I can't guarantee that it's 100% bug free, but I can say that I haven't seen a case of vault corruption yet. If for whatever reason at one point you suspect that the vault on dropbox is corrupted, please let us know as we'd naturally want this fixed ASAP.

B ) Overwriting another user's changes. If two users edit the same record, while offline then come back online, then dropbox will end up marking the record as being a conflict (it makes a copy of the file and names it such that we can see that it's a conflict). We fully support this scenario. We look at the two records and merge them as best we can. No changes should be lost. If both devices edited different fields, then the odds are that everything will turn out exactly as you'd expect. If both devices edited the same field, then the field value from one of the devices will end up in a conflict field (these typically live under the Conflicts section, but there are still cases where they sit next to the original field). Once we've done our conflict resolution, we clean up the conflict file. The goal is to never lose data. It can be hard for us to infer intentions, so in some cases we may mark the wrong field value as the conflict value, but you'll still have the data to move it back.

C) Overview of technique. Unfortunately we don't have a published knowledge base article about item conflict resolution yet. I'm intimately familiar with this code and am happy to answer whatever questions you may have.

I hope this helps. Let me know if you have any more questions.

Rick