Filesystem Read Key Flow

To get read access to a private tree/filesystem you need a read (AES) key.
The current flow for this goes as follows:

On filesystem creation:

  1. Filesystem creation happens simultaneously with account creation, thus both take place in the lobby.
  2. A read key is generated and stored in the local indexedDB.
  3. Using that same key we create the new private filesystem instance.

On device linking:

  1. In the lobby we take the locally stored read key and pass it securely to the other device.
  2. Other device stores it in the same way.

On app linking/authorisation:

  1. We get the read key from storage.
  2. Load the filesystem with it.
  3. When the filesystem is loaded we get the other read keys we need for the specific folders we grant the app access to.

What happens if the app is granted full private filesystem permissions? Does it then get the root read key or still some derived key?