I was looking for a reply in a post earlier this year but then found it's gone. This is kinda a downside, I wish old replies could be re-fetched, never thought it's "impossible to undo".
It could work in a way it would backfill the replies once the post is accessed, but tech-wise I understand if it's not possible.
Question for admins: Are you doing something to circumvent this?
On the other hand, that's what life is all about, things get lost in time. And that's one of the principals in my views and #MementoMoriSocial is based on this idea. Yet I want to retain as much that is possible, that's why I've left the field blank for now. Let's see how long it lasts before the next scale up. #MastoAdmin
@rolle honestly social networks like mastodon shouldn't be being used for a repository of information that needs to be permanent anyways, it's not really the intent nor are they particularly well suited for it, for long term content there's other fedi software that's better suited, whether it be for image posts, videos, or just text(blogs/etc), or even just using non-fedi software and posting a link here for discussions.
@raptor85 That is true, fast paced social medias like this are not the place. YET sometimes I want to go back in time and look for that certain thing. Or a bookmark. Those should not be deleted.
@rolle it should be retained. Social interactions evolve over time and referencepoints in discussions are invaluable, both in terms of content as well as for sentimental reasons.
I’m surprised to see so many comments arguing for regular wipes. I’m sure it’s feasible for some communities but many “mainstream” communities prefer longevity.
@rolle I can still see a lot of replies in the link you just posted.
Something I am still confused is about the difference between the setting you are referring to and the cron job that deletes the cached posts and profiles (tootctl media remove, tootctl preview_cards remove and tootctl media remove --prune-profiles).
In my understanding that tootctl command for media is the same than media cache retention period. Nevertheless, it being run still re-fetches media on demand. So it's kinda safer. But content cache retention removes the whole content permanently.
@rolle Oh, now I can see a lot less replies in the post.
With regard to the cache settings, I haven't ever used the media retention period, but the tootctl command triggers a process to build a temporary database identifying the toots and profiles that have not been interacted with and therefore considered ok to be deleted, so it is expensive in CPU usage but lesser destructive than a simple expiry date.
@rolle They’re not all gone for me! (But I don’t have all 134 either)
I guess it must be server-specific? Which kind of defeats the purpose if it is to delete everything…
@stefan For example this post should have 134 replies. They are all gone now. Including my replies to other users (because those replies I have replied to have been deleted).
@rolle totally. Refetch is hard because you would have to ask every mastodon server. Maybe a soft delete would remove the contents but point to where to get it.
@liaizon I was really surprised about the fact didn't notice this before. It's not "cache" if it deletes the things on your server. I noticed even one of my own reply gone because I had answered to a reply that was deleted... not good.
@rolle@jonne@husku@lari Muistivikaiselle olisi katastrofi, jos omat kirjanmerkit erityisen säilyttämisen arvoisista tooteista katoaisivat. Mitenkään ei voisi tietää, mistä on tullut käytettyä harkiten ajattelu- ja puhe-kykyä ja kaiveltua lähteitä. Pistäisi miettimään, kannattaako jatkaa tällaisella alustalla. Toki tarpeellisimmat saisi talteen vaikka OneNoteen, mutta olisi lisätyö, eikä pelkkä "päivä päällä" eläminen somessa jaksaisi meikäläistä kiinnostaa.
@lupposofi@jonne@husku@lari Onneksi Mastodontti.fi:ssä ollaan oltu hereillä tämän asetuksen suhteen. Onneksi itselläni ei ollut käyttäjiä aikaisemmin, joten vain omiini tulleita vastauksia hävisi. Näistä on helppo oppia.
@rolle@jonne@husku@lari Se tuli tosiaan "kreivin aikaan" varmistus siitä, että johonkin kohtaan ei toinna siellä päässä laittaa aikamäärettä, ellei tila ahista, ja sittenkin kai vain etukäteen tiedotellen.
@rolle I actually very much dislike what masto.host is writing there. The content retention cache policy is important for being a good citizen on Fedi.
A lot of users set an auto-deletion of their posts. E.g., "Auto-delete after 60 days". Then, their posts older than that are automatically deleted from their servers.
On remote servers which have fetched these posts, the posts would then disappear at latest this deletion date + the content caching policy set there.
If you leave that field blank on your server, you are actually saying: "I don't give a damn about what the original poster wanted, I am keeping their post forever."
This, for me, is being a not-so-good citizen of Fedi. If the post was deleted on your server after content retention cache time, it will be automatically re-fetched. If it was also deleted on the originating server, there was a reason for it and that reason should be respected.
I do NOT WANT the posts of my users to be kept longer than what they configured in their settings. I'd find this behavior ... not good.
And yes, there are many rules (also called "compromises") that we have to follow if we live in a community - and some of them I really don't like. But I have a choice: I either accept those rules, work with the others to change them, or leave the community. Because if one person starts breaking one of the rules, what stops others ignoring them all?
@admin Isn't auto-deletion another thing though and different from content retention? In my understanding posts should always auto delete per user if the user decides so regardless of the content cache setting? #MastoAdmin
@alex I am not sure whether the deletions are federated to everywhere. My understanding was that the deletions are like every other message action: they are federated to followers and/or mentioned people.
@rolle Yes, on their OWN server. But the cache I am talking is on OTHER servers. The auto-deletion works on their server where their post is deleted. It might also be federated to their CURRENT followers but definitely not to their "former" followers.
I am on the server 'anarres.family'. My post auto-deletion is set to '60 days'. Now, this post I am writing will be cached on your server, 'mementomori.social' for the time that your admin has set as 'post cache duration'. If that post cache duration is more than 60 days, this post will stay on your server even after it was deleted on my server after 60 days. If your admin has set '90' days, then it will probably stay another 30 days and then deleted from the cache and it is gone for good.
But if they left that field blank or set it to $MAX_INT, it will stay there forever even though I said it should be deleted after 60 days.
I have never said that cache retention has anything to do with user settings. I am just saying that if you set cache retention to forever, you might be ignoring the user's wish, especially as Mastodon, as described above in the link, can't really federate deletion to everywhere where a post has landed.
Well you said "If your admin has set '90' days, then it will probably stay another 30 days and then deleted from the cache and it is gone for good."
For me that exact same answer on the link makes sure the deletion will be federated but as like in the Internet, if your stuff is public, it may never vanish permantently, really. Look it up on Internet Archive, it can be found.
"it makes a best effort by sending to instances where there are followers and to people that interacted with or where mentioned in the toot, plus there are some delete forwarding paths in Mastodon".
I'm not going to argue about this more but it's safe to say per-user setting is enough and can be trusted.
@husku Joo, minäkin olisin halunnut tajuta tämän jo viime vuonna kun pistin serverin pystyyn. Tajusin vasta kun hiljattain tuli uuteen versioon tuo boldattu teksti... https://github.com/mastodon/mastodon/pull/23261
@StarkRG Yeah. Right now it just has ”All posts and boosts from other servers will be deleted after the specified number of days. Some posts may not be recoverable. All related bookmarks, favourites and boosts will also be lost and impossible to undo.”
@rolle
I'm personally leaving this field blank, but I can understand using it. Data loss is something to treat carefully, but those of us paying for a hosted instance do have to balance resources/costs with concerns like this.
@rolle Assuming the content is still available at thes origin, then If this isn’t redownloaded on demand, it’s not a cache. At the very least it needs to be renamed.
@rolle I completely disabled this function on my instance when I learned the scope of this functionality. I was shocked when I found the real scope in a Github issue. When I configured this, the text your instance shows was not yet there and thus a huge issue because it also wasn't in their docs.
E.g. for bookmarks this is an issue if you want to remember a post for a reason. :)
@rolle
I have media cache retention set to 28 days since it actually can and will be re-downloaded on demand. Content cache retention I have set to 365 but as that day approaches I might just set it to -1
@rolle I’ve probably lost some bookmarks because of this, since I didn’t consider that particular bit when I set it up.
I’m not going to turn it off, though. I’m probably just going to get in the habit of only using bookmarks temporarily, and saving things I care about to my regular computer (either links to the original post, or screenshots/copies of the text if it’s really important).
But yes: either this should either not apply to bookmarked or likes toots, or bookmarks and likes should continue to be stored as references to the original toot after it has been purged.
@michael Yeah, I guess I mistakenly thought it would just be removed and then re-downloaded on demand like media, not irreversibly removed. I have set it now to blank.
@michael@rolle currently yes. Ideally there should be a setting to activate the content retention period in order to purge old stuff, but keep likes & bookmarks of remote toots and remote replies to your toots intact.
@rolle
I found the same thing. When someone asks to follow me I like to see there own postings first. It would be good to have a longer window, maybe a years worth of posts could be the cutoff.
@rolle You can't guarantee that the originating instance will even exist anymore when you want to re-fetch things, nor that it will still serve up the content. Note it says they may not be recoverable, not that they won't.
@rolle But that setting is there specifically to delete them fully from your instance. It's only "completely deleted forever" if the content also disappears from its origin. If you want to protect yourself against that, you need to either back it all up or let your instance retain everything.
@rolle Incidentally, I think this is a poorly thought through setting, and that there ought to be an option to make the retention only apply to anything you haven't bookmarked or favorites and their parents (you might still lose some things but it'd be less surprising).
Add comment