Mastodon instance admin deleted all of our DMs after 15 days

Created on November 12, 2023 at 11:11 am

Mastodon PERSON instance admin deleted all of our DMs after 15 days DATE

October 2 2023 DATE

I’ve just migrated Mastodon ORG instances for the second ORDINAL time this year DATE . My new Mastodon ORG account is @[email protected]. Eight months ago DATE , I migrated to appdot.net because Mastodon ORG instance mstdn.plus with over 4 CARDINAL K users suddenly broke, and mastodon.social was not accepting new signups at that time. My first ORDINAL migration was triggered by an AWOL instance administrator; my second ORDINAL migration was also triggered by negligence, but of a different kind. A few days ago DATE I learned that the admin of appdot.net , without informing the instance’s users, had set the content cache retention period to 15 days DATE . Here’s the description of this Mastodon PERSON (mis)feature:

Posts from other servers will be deleted after the specified number of days DATE when set to a positive value. This may be irreversible.

The following warning was written to Mastodon ORG instance administrators by the company that hosts (but does not administer) appdot.net :

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

The current Mastodon ORG implementation makes this a dangerous setting and will indiscriminately delete remote content older than the number of days DATE 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 DATE has been reached, which is irreversible.

You can read a discussion I started in the Mastodon ORG GitHub about the consequences of enabling this setting to see if the Mastodon ORG dev team finds an alternative implementation.

Until Mastodon ORG releases an improvement for Content ORG 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 DATE ) or higher but any value set will still cause data loss.

To emphasize: any value set will still cause data loss. The worst of the many unpleasant consequences resulting from the content cache retention period of appdot.net is that, except for the last 15 days DATE , all of the direct (private) messages I’ve ever received from other Mastodon ORG instances are now irrecoverably gone. Of course the senders of the DMs still have access to their own messages on their instances, but I don’t! And appdot.net is a small Mastodon ORG instance, with only 80 CARDINAL users ( 79 CARDINAL after I left), which means that almost all of my direct messages came from users on other instances, and thus were deleted.

In an email exchange, the administrator of appdot.net explained why the content cache retention period was set to 15 days DATE :

I had it set very aggressively when we were on a lower tier as we were constantly running up against storage limitations. It was set to 15 days DATE . That’s no longer an issue, so I’ve upped it to 90 CARDINAL .

Needless to say, I was livid, and I decided on that day DATE to migrate Mastodon PERSON instances. 90 days DATE to data loss is not a whole lot better than 15 days to data loss! And of course the admin could not retroactively undo the data loss that already occurred. It’s important to note that every user of appdot.net is affected by this data loss, whether they know it yet or not. Hopefully they’ll see this blog post.

When Eugen Rochko PERSON added the content cache retention period to Mastodon GPE , there was some (though not nearly enough) discussion of the consequences:

I can see some issues with that, including losing bookmarks, the ability to signal other instances that you deleted your reblog of something (since you’d lose any record of that), or the access to any DMs. I don’t think the description does a good enough job of explaining that, and I think the feature should ideally avoid those cases in the first ORDINAL place.

Also:

If I bookmarked a post one year ago DATE . I expect it to be in my bookmarks one year later DATE , even if the server that originated the post is no longer online and the content cache retention period set by the admin is 6 months DATE . The same goes for boosts, favourites, DMs or posts I replied to. If we use the date as the single factor for deletion, we break functionality that I believe is important.

Nonetheless, the content cache retention period "feature" was released into Mastodon GPE , apparently without any further improvements or mitigations. Afterward, much later, the discussion turned to advice, sadly unheeded:

Any admin thinking of enabling this on their instance would do well to warn the instance’s users in advance, so that they have a chance to download an archive of their favorites and bookmarks (even better would be to send them such an archive right away by email: # 19400 MONEY ). Discussions will most likely become impossible to understand as messages are forgotten and relationships severed. Users can be advised to use mastodon-archive or similar to download their data before it vanishes.

This comment was prescient: "Discussions will most likely become impossible to understand as messages are forgotten and relationships severed." I actually discovered my data loss via broken public conversations rather than via broken private conversations. Although I had occasionally noticed some "orphaned" messages of mine in my DMs, I incorrectly assumed that the missing DMs from those private conversations had been been deleted by their senders. It was only after I learned about the 15 day DATE content cache retention period that I realized, to my dismay, that my own Mastodon ORG instance had deleted the DMs.

Below is an example of a broken conversation. On appdot.net there are two CARDINAL orphaned replies, https://appdot.net/@lapcatsoftware/110952859016087274:

And ORG :

Whereas on mastodon.social, you can see the entire conversation:

As the screenshots indicate, appdot.net has deleted data that mastodon.social retains, which is exactly why I decided to migrate from appdot.net to mastodon.social . By the way, threads.net is not a good or even a viable alternative to Mastodon ORG , unfortunately, as I explained in the blog post referenced in the screenshots.

Mastodon PERSON ‘s biggest problem is that the majority of Mastodon ORG instance administrators are unqualified, and unsuspecting Mastodon ORG users become the victims of shoddy administration. We’re told it doesn’t matter which Mastodon PERSON instance we join, but that’s a lie. My personal anecdotes described in my blog posts are far from the only ordeals inflicted on Mastodon ORG users by administrators: for example, many instances— some with thousands CARDINAL of users—have permanently shut down for various reasons, occasionally just for spite! Despite Mastodon PERSON ‘s ambition to be a decentralized network, I can’t recommend joining an instance other than the biggest one, mastodon.social.

Some people will say that I can’t complain, because Mastodon ORG is a free service. But that’s precisely the problem! You get the service you pay for: nothing. If we can’t depend on Mastodon ORG or on the Mastodon PERSON instance administrators, if data loss is just a natural consequence to be expected of a free service, then why should we use Mastodon PERSON at all? That’s a question for the founder of Mastodon ORG .

Addendum October 3, 2023 DATE

I wrote a follow-up: Your Mastodon PERSON archive omits DMs sent to you.

Connecting to blog.lzomedia.com... Connected... Page load complete