Mastodon: Rating Limiting on DELETE requests is absurdly restrictive

[dayvonjersen]

I want to delete all my statuses, every inane comment, every reply, all of it.

I do not want to delete my account. From this point forward I plan to delete everything older than 1-3 days every day.

I would prefer not to have an eternally preserved transcript of every message I have ever posted on Mastodon or anywhere else online for that matter. I would prefer for my messages to be ephemeral. I have the right to be forgotten.

Right now, statuses must be deleted with individual DELETE requests and are rate-limited at 30 requests every 30 minutes. Glancing at the source, this is a hard-coded limit. Using either the Web UI or the API results in the same restriction.

Effectively, one can only delete 1 toot per minute. As I write this issue, my script deleting 1500 messages will complete its task in 24 hours from now. If I had 15,000 that would be 10 days. This is absurd. If I had database access this would be a single operation.

Please consider doing one of the following:

1) Allow multiple statuses to be deleted in a single request
2) Increase the rate limit to something more reasonable (optionally make it customize-able per-instance)
3) Add a purge feature somewhere to let users choose to delete posts older/newer than some amount of time

[trwnh]

If I had database access this would be a single operation.

That wouldn't send out a Delete to other servers. The limiting factor here isn't your server, it's other servers. Another thing to watch out for is that each status deleted via the API also triggers an individual task in the Sidekiq queue, so it can make performance worse for all other users of the same server. See #9384 for an explanation of this.

On a local level, this can be improved. On a federation level, I'm not sure if there's any way around how expensive it is to be sending out a bunch of Delete activities in too short of a timeframe.

[irlcatgirl]

If I had database access this would be a single operation.

That wouldn't send out a Delete to other servers. The limiting factor here isn't _your_ server, it's _other_ servers. Another thing to watch out for is that each status deleted via the API also triggers an individual task in the Sidekiq queue, so it can make performance worse for all other users of the same server. See #9384 for an explanation of this.

On a local level, this can be improved. On a federation level, I'm not sure if there's any way around how expensive it is to be sending out a bunch of Delete activities in too short of a timeframe.

Why not allow server owners to allow users to queue their deletes? Knowing this is a federated network, users should understand that any delete or edit operation could take up to a few days for all servers to respect the change anyways and rouge servers can choose to ignore it.

[lapineige]

I've the same issues with the rate limit, that is so low than I wasn't able to delete more than ~20K statuses in 6 months. The current limit is really low, but we might also consider than the tools used to delete the statuses are not always running an a server (that might create some privacy issues), for instance if people use https://github.com/kensanata/mastodon-backup#expiring-your-toots-and-favourites, and as a result can't erase content all day long. As a result the "averaged" rate limit of 1 status/min can in practice become rather less than 0,5/min (assuming the computer is used 12h/day, everyday, which is a lot, and it will probably be a lot smaller).
In my case, I'm closer to 0,1 status/min, 1 status each 10min.
For some active accounts, 1 toot/boost each 10min can be really low.
So there an issue where you can't actually delete all your statuses as fast as your creating new one (and it takes forever to delete a bunch of old toots…).

Could there be another way to manage those deletion ? I don't know the technical part, but would it be possible to only delete the content when the server charge is low¹ ?
¹ either by queuing requests, or by raising the limit at that moment

For instance running the deletion during the night, as most servers connected are probably in a similar timezone (I guess ?).