Feature Request: Rate limiting inbound federation

What feature would you like implemented? The ability for server admins to rate-limit incoming API calls from remote mastodon servers.

Why should we add this feature? One of our instances, nsfw.lgbt, was brought to its knees the other day because a user on mastodon.world deleted over 30,000 posts causing mastodon to flood our server with over 6,000 requests/ hour. We had to block their IP in our WAF and even after we blocked the IP of the mastodon.world server we still have over 47,000 additional calls that were dropped before things finally slowed down.

Since then we have also implemented nginx's rate-limiting controls and are limiting calls to /inbox to 1 req/s per IP.

Version 2024.8.2

Instance nsfw.lgbt

Contribution Guidelines By submitting this issue, you agree to follow our Contribution Guidelines

• I agree to follow this project's Contribution Guidelines
• I have searched the issue tracker for similar requests, and this is not a duplicate.

marked this issue as related to #620

removed the relation with #620

marked this issue as related to #620

Slight correction - This isn't the API (to me that means misskey api, learn more at https://transfem.social/api-doc) but rather ActivityPub. I added that this is related to #620 because my original idea was based around this exact scenario.

added enhancement label

changed title from Feature Request: Rate limiting remote API calls to Feature Request: Rate limiting inbound federation

@bofhadmin The /inbox endpoint already has an internal queue. You can mitigate the impact of inbound federation by lowering the inboxJobConcurrency setting, and checking that clusterLimit is correctly set to the number of processors allocated for inbox jobs.

added federation label

We now have an enhanced rate limit service which could be used to limit the inbox, if that's something we want. It will need further discussion though. At a minimum, we will want to verify that other instance software understands HTTP/429 well enough to stop and try again later.

and also make sure our code handles 429!

mentioned in issue #842