This feels like a very pragmatic suggestion -- essentially "reference counting" the remote content.

I would be very keen to see something like this incorporated into the change as well. We do desperately need a way to purge old statuses more easily but I would be very hesitant to use it if it didn't discriminate between content that local users had interacted with and that which they hadn't. This would make it a much more useful tool.

Also worth noting that on many instances the storage utilisation is dominated by profiles' media rather than posts. #9567

One idea that comes to mind is to add a counter for each post. Every time a local user bookmarks, favourites, boosts, is mentioned on or replies to a post, the counter on that post increases by one. If a local user removes from bookmarks, favourites, boosts, or delete their reply, it decreases by one. This way, the cache deletion would filter posts older than X date and where the number on that counter would be zero.

This is an great suggestion to make this retention policy feature more useful. Hope it gets implemented.

I agree fully. After understanding the consequences of the retention policy, I set it to unlimited, as I would expect my bookmarks, etc. to be stable and existing, even after years. I would also like to ask to question, what about accounts that are in "monument mode" for instance, when someone died? I personally think till now, that I would like to keep the content of that account as well.

One idea that comes to mind is to add a counter for each post. Every time a local user bookmarks, favourites, boosts, is mentioned on or replies to a post, the counter on that post increases by one. If a local user removes from bookmarks, favourites, boosts, or delete their reply, it decreases by one. This way, the cache deletion would filter posts older than X date and where the number on that counter would be zero.

I think this could even be much simpler - probably in >99% of cases, once a user bookmarks, favorites, boosts etc. a status, they will not take that back later. So there could be just one flag "this status was favorited/bookmarked etc." that is just set once and never reset. If a post was favorited or bookmarked once, it almost certainly still is, so we can just as well keep that post without re-checking that. The additional storage savings we could get from trying to find all those statuses that were later removed from all bookmarks etc. would be minimal, for a lot more work.

Just realized this from here.

This value is blank by default, so it never deletes the remote content cache.

The current Mastodon implementation makes this a dangerous setting and will indiscriminately delete remote content older than the number of days set, whether the content was interacted with or not. Meaning, that no matter if a local user bookmarked, favourited, or boosted a remote post or even if a post is a remote reply to a local post, all will be deleted once the number of days has been reached, which is irreversible.

You can read a discussion I started in the Mastodon GitHub about the consequences of enabling this setting to see if the Mastodon dev team finds an alternative implementation.
Until Mastodon releases an improvement for Content cache retention period, I suggest leaving this value blank or, if you want/need to set it, make it something like 730 days (2 years) or higher but any value set will still cause data loss.

I just lost everything by enabling this feature. They are talking about cache, but in fact this is deleting data without the ability to update the cache. Fucking drug addicts who wrote about cache.

I've been told that an issue I noticed with posts in threads getting disassociated from one another might actually be due to this policy: https://social.treehouse.systems/@egallager/111898518131801953

This really needs to be solved at some point. As an instance admin I get to a point that I either need to ask people for more money just to host old external toots, ~99% of which nobody cares for by this point, or I have to enable the really darconian feature, fully knowing that I delete people's old bookmarks in the process.
Just adding a simple tick once the post has been interacted with and never changing it again would be so helpful in ways I cannot explain. I will turn this feature on in a heartbeat had this filter existed.

I had this feature on until I came across this discussion. Fortunately the policy was long enough that it wasn't affecting anything and my instance is new enough that there's not much to affect, but yes absolutely please build in a check for at least 1 bookmark on the local instance before it gets nuked. I'm not so picky about boosts, but if you want people to bookmark things, those things should still be there. I turned this feature off in a hot minute after reading this, and will turn it back on just as quickly if it gets fixed.

I agree as well. This is starting to bite us more and more as previous stuff gets wiped out. I personally would prefer it be any interaction and not just bookmarks (favs, boosts, been replied to).