Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync should prioritise new master keys and possibly other objects #828

Closed
JPvRiel opened this issue Sep 30, 2018 · 2 comments
Closed

Sync should prioritise new master keys and possibly other objects #828

JPvRiel opened this issue Sep 30, 2018 · 2 comments
Labels
enhancement Feature requests and code enhancements stale An issue that hasn't been active for a while...

Comments

@JPvRiel
Copy link

JPvRiel commented Sep 30, 2018

I assume this affects all clients, but I've only observed it on Linux and Android (haven't installed/tested others)

Operating system

  • Windows (not checked)
  • macOS (not checked)
  • Linux
  • Android
  • iOS (not checked)

Application

  • Desktop
  • Mobile
  • Terminal (not checked)

Feature Requests

The main issue I observed is there appears to be no prioritisation on how objects are synced. This increases the likelihood of conflicts and other complications.

Sync master keys first

I noticed a fair number of first time users (myself included) running into confusion setting up E2EE with a fairly large number of notes (e.g. importing evernote).

This can be avoided if the sync action prioritises first synching any new master keys?

Some other issues this would help mitigate:

Sync priority for other objects

Maybe there should be an overall sync priority for various objects in terms of importance and size:

  1. MasterKeys
  2. Tags
  3. Folders
  4. Notes with LIFO (not FIFO), i.e. sync notes by most recent modification date, since most recently modified items are more likely to be accessed first across devices?
    4.a New/Edited Note
    4.b then New/Edited Resource for note

Maybe to-do note types before normal notes?

And I guess other principles of cache coherency and reliability might apply well to sync use-cases, but I'm no expert on the subject.

@stale
Copy link

stale bot commented Sep 22, 2019

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "backlog" and I will leave it open. Thank you for your contributions.

@stale stale bot added the stale An issue that hasn't been active for a while... label Sep 22, 2019
@stale
Copy link

stale bot commented Sep 29, 2019

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.

@stale stale bot closed this as completed Sep 29, 2019
@lock lock bot locked and limited conversation to collaborators Oct 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Feature requests and code enhancements stale An issue that hasn't been active for a while...
Projects
None yet
Development

No branches or pull requests

2 participants