Discussion: Backup Import Conflict Resolving Strategy

[neruthes]

We are hereby holding a discussion on how should we design the conflict resolving strategy for importing database backup files.

[septs]

known issue:

1. Wallet merge logic - undefined behavior

[neruthes]

List of certainly mutable data classes

• Persona-Profile Pair (Persona with Private Key)
• Persona-Profile Pair (Persona without Private Key)
• ProfileGroup Profile Membership

List of supposedly immutable data classes

• Post

[neruthes]

Case-By-Case Study: Persona-Profile Pair

Background

Persona-Profile Pairs may be categorized as:

• Claimed Pair
• Witnessed Pair

For each pair, Maskbook should record the update time and the witness time. If the type is Claimed Pair, the witness time and the update time should be the time when the user created the claim.

Real Conflict

Suppose that Alice has multiple SNS-Specific Profiles (SSP) and 2 devices, and the databases on the 2 devices are identical at the initial condition.

When Alice disconnects Alice_SSP_1 and connects Alice_SSP_2 at SNS_1 on Device_1, the old record will be deleted, and the new record will be added. When merging the backup of Device_1 to Device_2, there will be a real conflict. Alice_P (the Persona of Alice) now has a different SSP for the given SNS.

In this case, we need a conflict resolving strategy which can be:

• Ask the user which version he wants to retain (preferable)
• Automatically use the newer version

Specifically, when the private key of the Persona does not exist in either database, it would be dangerous to ask for user confirmation, because there can be too many of them.

Fake Conflict

Suppose that Alice has multiple SNS-Specific Profiles (SSP) and 2 devices, and the databases on the 2 devices are identical at the initial condition.

Alice disconnects Alice_SSP_1 and reconnects Alice_SSP_1 at SNS_1 on Device_1, or Alice connects Alice_SSP_3 at SNS_2.

When merging the backup of Device_1 to Device_2, there will be a fake conflict. Alice_P remains the same although certain timestamps are different.

In this case, no conflict happens; Maskbook should use the version whose witnessedAt is later.

Notes

• A Claimed Pair can become a Witnessed Pair, and vice versa. When merging databases, a Claimed Pair should always override a Witnessed Pair. However, Maskbook should figure out whether the private key of the Persona exists in the database which includes the Claimed Pair record, in order to determine whether the record can be trusted. It is possible that a Claimed Pair remains when the private key is deleted (debug-level database operation, etc).