@nik@Moon@feld@tedu I think it's the job handler. Mastodon has sidekiq and it's set up to basically queue up the jobs in different priorities and handle them as the server has capacity. I think pleroma just has something more basic iirc
There is I think a custom MRF going around that rejects them but I am using a built-in MRF called Vocabulary that can be configured to reject Delete activities.
also like, when I was working on my (defunct) activitypub-enabled blog, I shared a post with two servers and within minutes I was getting spammed with deletes from random mastodon instances. I don't think the actual spam problem is solvable though . I kind of feel like if activitypub (in its current state) was the protocol that everyone used, that this problem would be a complete obstacle to scaling.
@feld@Vril_Oreilly@i@mischievoustomato@Moon If you make the number of concurrent delete operations configurable, I don't see any problems. Remote deletes aren't fast anyway and it's unreasonable to assume that account deletions will be fast. Maybe you could pretend the account was deleted and process the post deletes from mastodon silently in the background.
@feld@Moon@Vril_Oreilly@i@mischievoustomato To clarify what I mean by pretending. If someone asks BE for an object that is marked to be deleted, the BE replies that the object is gone/non-existent. Theoretically this way it won't show up in threads on the frontend and everything would look normal from the outside.
@FUCKINGWHOCARESDUDE@feld@tedu@mischievoustomato@Moon I think this (and the vocabulary-based reject) breaks deleting local activities as well, hence why everyone's using custom MRFs that reject Delete activities only if its origin instance's domain isn't the same as an actual instance it's running on.
Add comment