Delete Object History & Set History Limits

Feature Requests
,
1

Is your feature request related to a problem? Please describe.
The entire history of a page is remembered for each pages currently. This is a good feature for many people. Myself and I guess a lot others would also like the ability to instead limit the history to say the last week / last month / last N days / last 100 entries. This would help one in reducing the amount of storage used and will also help to declutter the data in Anytype.

Describe the solution you’d like
A global setting which can be changed to the number of days of history to store for each pages / Last N number of history to store / unlimited history. This should also delete the old images / icons used in the history when the history is removed.

Additional context
Page wise option would be great but seems like an overkill.

2

:clap:t2:

Sounds like obvious need for an Offline first data storage software.

3

One thing I’ve observed about Anytype’s Version History page is that it seems to keep changes on an extremely granular basis, even going down to the individual word that’s been typed. While keeping these extremely granular version history logs are important for the “Control+Z” functionality, we probably don’t need this amount of granularity for changes that were made months or years ago.

Therefore, in addition to creating a limit for the amount of time version history is kept, perhaps, Anytype can automatically reduce the granularity of old history entries in order to save storage by only keeping the top level entry and deleting the sub-entries (seen in the version history view), rather than for every edit that’s been made. This should allow users to go back and restore the document to previous states, while still saving on storage by reducing the amount of states that are saved.

However, I do have to question how much impact version history, especially for text-based documents has on disk usage, as pure text shouldn’t take up that much space. Perhaps there is another underlying issue, not the revision history, that is causing problems around excessive storage usage?

4

True, this is also one reason for increased storage since not only the word is getting stored, meta data for that version such as the name, version number etc, are getting stored for each version entries which adds up to the large storage usage in the long run

It will not be an issue during the initial few months or years, but if one wants to use it for several years, unnecessary version history of all pages adds up to a considerable amount of disk storage.

By purge, I mean not only the page contents, but also the display pictures and older cover images which are not needed anymore.

I’d also be happy if other media files linked to the page is removed as far as it is the only place it is referenced, but that is debatable

5

Perhaps make a system where granularity decays the further back it goes.

For example, keep full granularity for the past couple of days. Paragraph level granularity for past week… etc. For changes done a year or more ago, it’s enough to keep page-level changes.

I’m sure it’s much (much) more complicated than that… But just a thought!

6

Good day!

There is a suggestion for choosing options for saving the history of changing objects.

The bottom line is that in my opinion, it is logical to let the user choose how much the history of changes of an object should be stored, since many backups occupy an impressive amount of space on the hard disk. For example, my database actually has a size of 65 MB, but due to several dozen backups, the application and all stored information takes 1.5 GB. And this is only at the beginning of use, I don’t have much information in my database yet, but the potential for its appearance is quite large. This is not so much for a PC, even if you end up with 10-15 GB, but in the case of a mobile application, the same 15 GB is a pretty impressive database size.

Accordingly, it would be nice to be able to choose whether I need to keep a history of changing notes for, say, more than 2 weeks.

Thank you for your attention.

9

WHAT DO YOU RECOMMEND

Define a specific feature that is missing or could be improved:

Delete history version: This feature would allow users to permanently delete specific versions of a object or document. This could be useful for removing outdated or incorrect versions of a object, or for freeing up storage space.
Limit history version: This feature would allow users to set a maximum number of versions of a object or document to be stored. This could be useful for preventing a file’s history from growing too large, or for managing the number of versions that are available for restore.

10

Objects don’t use storage space, only files do. So the version history has no effect on that.

11

so does the size of those files increase over time?

12

Which files?

Files don’t use version history at the moment, and they are the only ones that count for storage limits at the moment.

13

Is version history of files a future feature?

14

Possibly. Files were recently reworked to work more like regular objects, but you still can’t edit the files themselves after you upload them to Anytype so that would first need to be implemented.

15

This is much needed, especially for an app like Anytype that is privacy centric.

Because it’s not very privacy-like if every member that is in a space can see all version history of all written objects, even the version history logs before they were added into the space.

An analogy would be like getting into a relationship with someone, and they’ll be able to see everything you’ve done in your past, the date and time you’ve done them, just from letting them into your life. They’ll be able to see that time where you litter, that time when you argued with an ex, that time where you ate the booger from your nose, that time when you were acting a fool alone in your own room when you were a kid etc. even when they haven’t even met you yet when those things happened.

Just inviting someone into your Anytype space, they’ll be able to see all the changes made to the object, down to the very first letter written of the very first word on this object, of any written object in that space; even when they weren’t an Anytype user when those objects was created.

Imagine sharing your space with the current partner and they go around snooping in version history to find out stuff that you and an ex did privately, even though you’ve already deleted those information from the pages after breaking up years ago. This is not privacy centric. I’d say this is even worse than the phrase: “Everything you say can be used against you”, as this is not just what you say at that very moment, but everything that you’ve ever said (typed) in the past as well.

Imagine having a shared space with the whole family. You copied something that you wanted to paste into a page for everyone in the family and extended family to see, something distracted you and you had to deal with that first, comes back later and remembered you wanted to paste what you copied into the page for the family. After pasting, you realized it was not what you wanted to share and forgot that you copied something else while distracted earlier; you can delete it, but it’ll still be there in the version history. What if that block of text pasted was a kinky paragraph you typed out for your partner? What if it was something for the the therapist about how your parents are mistreating you? What if it was proposal plans that your girlfriend should not know about?

Those are heightened scenarios, but it could definitely happen, yet it’s preventable by having the ability to clear version history, set a timer for version history, make version history only visible to the space owner, or maybe even make version history visible only to the very person that made the change for that particular version.

16

I would like to see the following features for history

  • Ability to disable/enable history in a space and account wide
  • Ability to set a history limit by X amount of versions
  • Ability to se a history limit by X days
17

“Objects don’t use storage space” …but the data has to be stored somewhere, no?

Even if Anytype does not count it to official storage limits, it still takes up space on devices or self-hosted servers. For most people, that isn’t going to be very much if I understand right that it tracks changes like git rather than save full copies, but it would still be good to be able to manage it, and it can be an easy way to save space.

18

I think this part makes no sense. Git actually saves full copies. It stores a snapshot of the whole repository on every commit and the space is saved by compressing that snapshot (which compresses well because it mostly repeats the existing content + new changes). However, with CRDTs there are no snapshots. I mean, you could make one, and this is what the current version of an object is.

I think most people think in terms of Git, where the history is a series of snapshots. My feeling is that with CRDTs, if you delete part of the history and then synchronize with a device that still has that history, you are going to get that back. Even worse, I can’t imagine what happens if you synchronize with a device that has made changes to the blocks in the past, you have deleted history in that period, and now the app tries to synchronize their changes but you don’t even have those objects.

I know that, in practice, the likelihood of this happening is fairly low but it goes to show how CRDTs work (and why). Probably, we’ll need to be able to make snapshots (meaning, delete history up to certain point) and accept that there won’t be any changes synchronized before that (a paradox!).

Also, I think it will be next to impossible to have stuff like “1 change per month” because that’s not how changes are tracked here. I highly recommend to watch some introductory videos to CRDTs.

19

Thank you, I had a misunderstanding of how git worked, but now I understand that it uses a content-addressed structure that makes it efficient to save the snapshot when most of the content hasn’t changed.

It makes sense that the history has to exist for synchronization, making a history deletion feature much more complicated than it sounded, unless it’s just a UI decision to not display the history despite that the device has it.