Really though? You can implement the same limits for federated posts, and just drop the ones exceeding the rate limit. Who knows, might be frustrating for normal users that genuinely exceed the rate limits, because their stuff won’t be seen by everyone without any notice, but if they are sane it should be minimal.
The notice might still be able to be implemented though. idk how federation works exactly, but when a federated post is sent/retrieved, you can also exchange that it has been rejected. The local server of the user can then inform the user that their content has been rejected by other servers.
There are solutions for a lot of things, it just takes the time to think about & implement them, which is incredibly limited.
Federated posts are received, and they can come in batches. If a server was down for a while, you may receive days or even weeks of data, all at the same time.
In this case, the spammer is probably using an account on a real server, so that server needs to take action and ban the spammer. If the attack is federation based, there’s nothing stopping the spammer from faking time stamps, usernames, and using hundreds of different domain names.
You can use heuristics to flag accounts to admins, of course (“this user is sending 2000x the normal amount of posts and comments”), but it’s impossible to prevent spam without whitelisted federation.
This is why email providers such as Gmail, Outlook, and Apple mail flag almost any email from a small server as spam, regardless of message contents. There are too many spammers out there, and only trusted, somewhat verified servers are allowed to send email. It’s a real pain for those running their own mail servers.
Not to suggest it isn’t a problem that needs to be solved. But from my understanding of activitypub protocol, there isn’t a way to control content federation on a per message basis, solely on allow/block instances as a whole
Really though? You can implement the same limits for federated posts, and just drop the ones exceeding the rate limit. Who knows, might be frustrating for normal users that genuinely exceed the rate limits, because their stuff won’t be seen by everyone without any notice, but if they are sane it should be minimal.
The notice might still be able to be implemented though. idk how federation works exactly, but when a federated post is sent/retrieved, you can also exchange that it has been rejected. The local server of the user can then inform the user that their content has been rejected by other servers.
There are solutions for a lot of things, it just takes the time to think about & implement them, which is incredibly limited.
Federated posts are received, and they can come in batches. If a server was down for a while, you may receive days or even weeks of data, all at the same time.
In this case, the spammer is probably using an account on a real server, so that server needs to take action and ban the spammer. If the attack is federation based, there’s nothing stopping the spammer from faking time stamps, usernames, and using hundreds of different domain names.
You can use heuristics to flag accounts to admins, of course (“this user is sending 2000x the normal amount of posts and comments”), but it’s impossible to prevent spam without whitelisted federation.
This is why email providers such as Gmail, Outlook, and Apple mail flag almost any email from a small server as spam, regardless of message contents. There are too many spammers out there, and only trusted, somewhat verified servers are allowed to send email. It’s a real pain for those running their own mail servers.
Even a “normal” user needs to chill out a bit when they start reliably hitting a (for example) 3-post-a-minute threshold.
Not to suggest it isn’t a problem that needs to be solved. But from my understanding of activitypub protocol, there isn’t a way to control content federation on a per message basis, solely on allow/block instances as a whole