GitLab

Problem statement

The current AccountModel implementation potentially does I/O for each and every property update for each and every account.

The way the current model works is, as far as I can tell, by calling storeAccount() for any property change. This has a number of downsides:

1. If multiple properties change for one account this results in a series of I/O actions.
2. As far as I can tell the all accounts must be written out for any one property change.
3. Even when properties are being set to invalid values (lack of validation)
4. I/O is done from the same thread/context as the property change. This may be the "main" UI thread. This is potentially quite slow (e.g. NFS) blocking the UI.
5. There is no way to communicate any kind of feedback to the user, e.g. if some kind of I/O error occurs.

UX issue: instant-apply/instant-commit.

The current implementation is also implicitly instant-apply/instant-commit. In particular there is currently no way to undo changes or to restore to a previous configuration easily. For the most part this is not a deal breaker, but e.g. for an edit account details page this is quite awkward because we cannot easily let the user cancel the edit form.

For the most part a token configuration only makes sense as a set of properties. I.e. all the properties must be set to their correct value, and selectively altering just one property is mostly not useful by itself (with the possible exception of the HOTP token counter). This is because deciding on the desired values for these parameters is not really up to the user, rather they are inherently be imposed by whatever 2fa account the user wants to login to. They are simply hard technical parameters, not freely configurable user preferences. E.g. it makes no sense to alter a token length from 6 to 8 because "it feels more secure" or conversely from 8 to 6 "to reduce typing", simply because services will generally require a particular fixed length token. The only reason to alter a token length field is because a mistake was made when creating the account originally, or perhaps because the cat got hold of the keyboard and everything is messed up now.

Therefore we would expect a user to tweak settings until they 'match' whatever their service provider may indicate in 2fa instructions. In turn this means any update to a property only makes sense together with the related updates to other properties. Hence it may be preferable to commit changes only once we are sure the user has fully updated the account configuration.