[Feature Request] Document version history

[Mello7sh3i]

Hello, (first, sorry if the subject has already been mentioned, but I didn't find anything)

Is your feature request related to a problem? Please describe.

In "documents", I would like to have a history of my notes.
I may accidentally delete something without realizing it, or I may delete it intentionally, but need to retrieve what I wrote later

Describe the solution you'd like

Have in the right tab a "history" button that allows to find a version of my note.
This can be implemented in many ways:
manual or automatic snapshot. Keep the history for a defined period of time, or a defined number of versions.
I don't know which way would be the easiest. Personally, a manual snapshot would be enough for me.

Additional context

There is currently the possibility to make a copy or to export your document, but it's not the most optimized use to have a backup of many documents.

Thank you very much for your work

[johnozbay]

Hi there!

Thanks a million for filing this!
This question / request comes up every now and then, and there's actually a pretty good technical and security reason why we unfortunately can't / don't support versioned document storage. [But I really like your manual snapshot idea a lot, and more on this below]

---

Briefly, some background — we don't version documents for encryption security & integrity.

Let's say you have a document with just "test" as text inside – and typed :
"t",
"te",
"tes",
"test"

And save it 4 times for each keystroke, and there's 4 different encrypted versions, we think this process of storing multiple content-inclusive versions of an encrypted document could one day theoretically compromise encryption security and integrity in the long run if/when some day in the future someone invents a theoretical way to abuse this. (no such theoretical attack exists as of today as far as we know, but we didn't want to risk it, and we'd rather be safe than sorry basically)

And regarding cost, with 10GB storage, and 10 versions of each file, it would amount to 100GB of storage/user. – since we can't do delta-writes/delta-updates like Google Docs (i.e. send each character separately and create the words on the server) due to on device encryption (which means our servers can't merge individual characters into words, since they can't see your documents due to encryption), and have to encrypt & upload the whole document each time, we have to upload whole documents, and the cost grows VERY quickly.

---

We are however looking into something like an in-session undo. i.e. the ability to retrieve the last deleted document as long as the tab remains open. However even this introduces some security issues. i.e. when computer goes to sleep, browsers actually freeze tabs, so this deleted document could sit in memory for incredibly long periods of time.

Or if a user temporarily writes something critical in a document i.e. a bank acct number, a password, something sensitive, and deletes it later — the general assumption would be that this is deleted and gone. But with versioned storage, you can never be sure if something is deleted or not. And we don't like the can of worms this would open from a threat-modeling standpoint for individuals who are at risk.

---

I really like the idea of a manual snapshot list, even though I'm not sure how it would work just yet (since we would need to update our document filetype/format structure a bit to accommodate for manual snapshots/versions) I'm going to put this on our weekly agenda to see if/how we can make this happen.

If we were to add a manual snapshot list (i.e. up to 10 snapshots), where you can recover / restore / delete these snapshots manually, would this address your use case?

Many thanks for filing this once again!

Looking forward to hearing!

Best,

[Mello7sh3i]

Hello, Thank you for your answer, and the explanations given, I understand that the implementation isn't easy technically and that the constraint of storage is necessarily to consider.

I really like the idea of a manual snapshot list, even though I'm not sure how it would work just yet (since we would need to update our document filetype/format structure a bit to accommodate for manual snapshots/versions) I'm going to put this on our weekly agenda to see if/how we can make this happen.

If we were to add a manual snapshot list (i.e. up to 10 snapshots), where you can recover / restore / delete these snapshots manually, would this address your use case?

In my case, yes, that would be perfect.
I hadn't thought about it, but the ability to delete a snapshot is an excellent option !!

Thank you for taking the time to answer me and consider my request, I wish you a great week.

[eugenesvk]

And regarding cost, with 10GB storage, and 10 versions of each file, it would amount to 100GB of storage/user. – since we can't do delta-writes/delta-updates

Why not? Can't you make the client do the diff operations and then store only the encrypted deltas? It shouldn't be a delta for every single char, but auto-saving every hour or on log off should be workable

But with versioned storage, you can never be sure if something is deleted or not

There are a couple of solutions to that

• A user can use a new 'purge' button/command to delete all diffs in a note to be sure no history remains
• A user can mark some document as no-history documents (or even make it the default make enabling history for a note an opt-in)

If we were to add a manual snapshot list (i.e. up to 10 snapshots), where you can recover / restore / delete these snapshots manually, would this address your use case?

I'd strongly prefer something automatic (could be in addition to manual snapshots), it's too much of a mental overhead to have to remember to backup especially when you're used to have it done automatic is some other text-editing workflows

[pabloscloud]

(or even make it the default make enabling history for a note an opt-in)
That results in an inconvenience when a user forgets to enable the feature he can't see the histroy and throws the ball on cryptee why this isn't the default.

[eugenesvk]

(or even make it the default make enabling history for a note an opt-in)
That results in an inconvenience when a user forgets to enable the feature he can't see the histroy and throws the ball on cryptee why this isn't the default.

1. That's a smaller inconvenience vs. having no option
2. You can always make the opposite the default depending on how you weigh the different convenience/security parameters or make it an account-based setting with note-based exceptions for those who need them