Afaik, whenever an Activitypub instance has defederated from another it has always had to do with some combination of bad user behavior, poor moderation, and/or spam. Are the various instance admins who have decided to preemptively block threads.net simply convinced that these traits will be inevitable with it? Is it more of a symbolic move, because we all hate Meta? Or is the idea to just maintain a barrier (albeit a porous one) between us and the part of the Internet inhabited by our chuddy relatives?
(For my part, I’m working on setting up my own Lemmy and/or Pixelfed instance(s) and I do not currently intend to defederate.)
Honestly, I feel like the bigger issue is the immense flood of content that’s going to pour out of Threads. I’m not sure if many of the self-hosted instances will be able to federate with it and continue to function.
This seems like a more viable argument than much of the EEE stuff, in regards to Threads v Mastodon.
But I simply don’t understand the ins-and-outs of how Threads stuff gets federated, and how much toll it would actually put on other servers.
My (limited) understanding of ActivityPub is that it functions on a publish-subscribe model. If you and I both ran instances and federated with each other, every time a message was posted to my instance I’d send a message to you and vice-versa. Now, let’s say a new person comes along with their own instance and they want to federate with us, but they have 1000x more users than we do. If we federate with this new instance, we now both have to handle 1000x more traffic.
This is effectively a Denial Of Service attack.
Threads currently (supposedly) has 70 million users. If only 0.001% of those users are interacting with federated content every second, that’s still 1000 messages every second. Smaller instances are likely not configured or tuned to handle this level of traffic on top of their existing traffic.
What kind of sever requirements are needed?