Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Local messages store #32
This is considered as a priority one missed major feature:
There potentially might be many email messages content getting options, like at least:
At the initial stage it's not going to be a comprehensive bridge-like thing, but more like email provider's web UI supporting thing. The initial implementation is not going to keep locally stored messages in sync with the server/actual state. Means it would be a one-off putting to local cache action, with no further message state updating (message got unread state, got removed, got changed folder/label, etc).
A brief workflow steps description:
I was exploring existing Node.js compatible embedded databases with built-in encryption support and have not really found solutions that would keep metadata encrypted as well. Means, it's possible to encrypt values of specific columns/fields, but metadata remains unencrypted. Metadata is for example information like how many rows in the database you have, what is the columns set, empty/filled cells, etc. But such information in some case can also be considered as sensitive.
So I'm considering the following approach. App keeps all the messages in memory. App flushes these messages to the encrypted file with some interval and probably on some triggers. This file would be a brick of bytes, fully encrypted, including metadata, similar to how
Database encryption key would be generated once and stored in
referenced this issue
Jul 18, 2018
I was exploring Tutanota's entity event batch stream and have realized how to efficiently utilize it in app. So it's going to be a complete offline emails storage, including the state syncing part. Messages fetching and syncing is already pushed into the master branch.
Encrypted database persistence has just landed into the master branch. So backend logic is completely done for Tutanota and it works efficiently enough. Which means building minimal UI around the local messages store is only remaining blocker for releasing the feature. Alternatively, I'm considering releasing the feature only after the Protonmail also gets backend logic done. I've not even yet started researching Protonmail's Rest API though.
This was referenced
Sep 6, 2018
I was exploring the possibility to enable conversation view mode for local store viewer, which is in general a demanded and not yet supported feature by the official Web Client, ref1 / ref2. And it looks like a quite possible thing to do with still remaining issues to sort out though (see the weird, 2nd-level, grayed out removed message):
Conversation shown on the example screenshot is 3 level hierarchy conversation. Hierarchical tree-like displaying is possible because Tutanota keeps the conversation structure using nodes with parent/previous reference model.