TL;DR: The common view on Meta’s Threads is that it will be either all good or all bad, leading to oversimplified and at the end contra productive propositions like the Fedipact. But in reality, it’s behaviour will most likely change dynamically over time, and therefore, to prevent us getting in a position, in which Threads can actually perform EEE on us, we need to adapt a dynamic strategy as well.
The current problem is that Threads is coming, but our current look on things is too simplified (we either see it as all-good or all-bad), which is why we have no sufficient handle against Thread’s potential advances.
To find one, we will first define a more nuanced and realistic concept for the federation behaviour of instances in general, after that observe different behaviours of instances and finally, come up with a new, general strategy to counter threads and other abusive instances in the future, to ensure the health of the overall Fediverse.
1. Problem Description
Note: After doing some reading, I came to know that the current debate in the Fediverse is in fact already much more complex, but my overall point is still relevant to the debate, I think.
Currently, we see instances still through a romantic glass and that was fine for building the social web, but with its currently starting commercialization, we need to change that to survive.
What we gained from the Fedipact/no Fedipact debate is the realisation that federation alone is not enough to ensure a functioning open social web. My proposition would therefore be to nail this down in a federation policy and enforce it as best as possible against Threads thus creating a new environment of like-minded instances that prevents the merge of an abusive EEE-instance; and try to get Threads to follow these rules as best as possible, or else take measures accordingly.
From the point of view of an instance, we see the potential behaviour of Meta’s Threads too often as either all-good or all-bad. Either it behaves nicely and federates, or it completely swallows us with EEE. In this scenario, depending on which side you are on, either the Fedipact seems like the most sensible approach: to block Meta entirely; or the approach to federate with Meta completely no matter what it does.
However, this view on things is limited and even misguiding for three reasons.
First: there will always be the possibility of abusive instances or instances becoming abusive and there needs to be a handle for these things. They could also be non-commercial ones and most likely, they already exist on the Fediverse, strategies against them are just carried out “on the go”. While corporate instances are probably more likely to be/become abusive, it would be nice to acknowledge this and talk about general ways to act here.
Secondly: as a company that has to adjust its behaviour on multiple factors (revenue, public image, legislations, etc.), it is much more likely that Meta’s strategy will change based on these factors. On the one hand, Meta has an interest in keeping the Fediverse ecosystem alive, both for public image, a reduction of societal responsibility and to ensure the growth of this market (which they want of course, but also not so surprisingly, to dominate). But at the same time, Threads will, at least at times, most likely be an abusive instance as well. Meta behaved abusive in the past, if Mastodon is drawing too many users from Threads, it will most likely fall back in this behaviour, as we are already seeing in the fact that Threads will make Federation for its user’s opt-in (while data reclamations could actually contribute to this as Meta tells us, it’s probably also because they fear to lose users).
And thirdly and most importantly, a big misconception about EEE is that it could have easily been avoided by just blocking out the new, aggressive instance and we can now learn from this by just blocking Threads no matter how it will behave. However, XMPP didn’t just die because it opened itself up to Google and got extinguished, it also lost significant relevancy independently from this. This is something that should always be kept on one’s mind: people can just leave for other servers, and they will. That’s always the consequence of defederating big instances: network effects kick in and you will lose members, which is not sustainable to put up permanently or it will result in a position, in which you have become so irrelevant that the big instance can perform EEE or doesn’t even care anymore.
And because all of that, both a more general and more dynamic strategy is needed to counter abusive instances like Threads and at the same time ensure the health of the instance for the future, for which both of the current approaches are unfit. Because then, growth will just happen in other parts of the Fediverse and we wouldn’t be part in shaping the future of the Fediverse, which could as well result in a situation, in which EEE is performed on us – we will no longer have any influence over it anymore.
Derived from these misconceptions, we can already declare some basic requirements for the new federation strategy:
1. It should reduce risk that a single instance comes into a position in which it can perform EEE on the overall Fediverse (like in the case of XMPP)
2. It should foster the instance’s own health
While none of the two currently debated approaches meets any of the two points sufficiently, it is impossible to make sure both of them are met entirely, without becoming authoritarian and effectively performing EEE itself. That’s why a third requirement should be added:
3. New instances need to be able to join instance groups that an instance could belong to and the Fediverse in general; and should have a chance to grow in their environment to ensure future innovation thus reducing risk that instance groups themselves come into a state of wanting to become abusive and perform EEE on others (like some parts of the Fediverse basically wanting to cut off Mastodon from corporate instances in general). It would also guarantee ongoing innovation.
The new strategies’ goal will be to meet these points as best as possible.
2. Definition of Federation Policies and Strategies
But before we can think about how this could look like we need to observe the general behaviour of instances with regards to their federation policies in general. For this, we will at first define some concept and in the next section, make observations with them.
2.1. Federation Policies
The central definition is that of the federation policy: a federation policy is the degree that the instance opens itself to the other instances. Instead of the two extremes “walled garden” and “fully open” I will introduce a policy scale that spans over all possible policies in between them:
As the two poles are self-explanatory, everything in between consists first of all in the fact that federation is implemented, but also more “soft” rules, e.g. on how prominent it is advertised in the UI of the clients and to what degree user attention is directed out of the own instance or their handling of hateful content and bullying.
Instances will in the following sections be depicted with respect to their position on the federation policy span as in the following picture:
Of course, instances are not fixed on this scale but can change their policy dynamically:
As can be currently observed with Threads. We can now see how limited the current look on Threads federation is: we think that it will stand on one of the two poles of this scale: they are either almost fully closed and abusive, or fully open. But between them, more practical federation policies exist on which Threads will much more likely wander dynamically over time and to which the rest of the Fediverse has to react accordingly.
2.2. Other Definitions
It should also be said that there are of course also dynamics that have been observed before like network effects: Networking effects lead to the effect that over time, in a network of walled gardens, the network with the most members will drain energy/health from the other networks.
In general, we will in the following continue to take the view of a single instance to make use of the federated nature of the Fediverse. How policies are actually come up with can of course very and also be integrated in some processes or committees.
In the depiction of the next sections, the size of the instance’s spheres will be the number of members and overall health of the instance. The environment of an instance are the instances that the instance federates with and later, instances with the same shared minimal federation policy.
3. Observed Behaviour and Rules of Instances of different federation policies over time
Of course, instances not necessarily stay at one position of this span, but adjust it dynamically based on environment’s policies (other instances they federate with) and the state/health of the own instance. In the following, rules with derived from that with respect to their environment and their federation policies.
3.1. Instance Protectionism
First of all, there is instance protectionism, which can already be observed on the Fediverse today. I define it as a significant shift of the federation policy of an instance in reaction to the federation policy shifts of other instances or in reaction to the fear of losing members, resulting in an overall shift of federation policies and a decline of health in the observed environment in general.
On Lemmy for example, this was observed when instances put their local feed as the default feed on their browser’s UI in reaction of 2023’s problem with CSAM imagery as well as the same behaviour from lemmy.world (which they have by now, changed and even promote smaller communities from other instances on their home page of the client UI).
Instances, especially smaller instances, have an interest in keeping their members on their instance to prevent dying, which is why, if too many other instances practice instance protectionism, they will do it, too, resulting in all instances practicing instances protectionism.
Like in global economics, instance protectionism can be seen as the prisoner’s dilemma that can be observed in many situations in our society, for example during the COVID-19 pandemic with shortage of toilet paper supply and as we will see later, usually only can be prevented by reminding people of their shared interests, an over-availability of the demanded resource or a common penalty of selfish behaviour.
This is especially true for environments, in which content is valuable beyond its users and cannot be taken with them if they migrate, for example on Lemmy, where a communities’ knowledge is aggregated independent from its users. That’s why, instances will try to get as much of that knowledge as possible, because it will increase their lifespan: having a valuable Lemmy community on your instance is very good. Also, users will drift towards the servers on which their communities and most nodes of the social graphs are. That’s why a promotion of the local-feed as the default feed, is in the interest of the average Lemmy instance if it has no consequences, but will result in an overall decline of discussion quality and health of the Lemmyverse.
However, with the biggest Lemmy instance, lemmy.world, changing its default feed to all and even promoting communities of smaller instances, maybe this will be the start for a shift away from instance protectionism on Lemmy. So, instance protectionism is a difficult problem, but one that can be dealt with if big instances take responsibility.
3.2. Instances drift toward the policy of the most influential instance, which in an unprotected environment, leads to instance protectionism and ultimately, a transformation toward walled-gardens and the creation of a monopoly
As already partly described in the last section, in an observed environment, there is a drift of policy toward the biggest actor’s federation policy.
Why? Because members of the smaller instances can read all of the big instances’ posts, but their own posts get way less attention and therefore interaction, because they aren’t read by the big instance. This way, members will flee toward the big instance and the smaller instances will need to draw measures accordingly to save their own instances health. That means, because of network effects, it draws members from the other instances, abusing its power.
This results in closing of federation, e.g. by advertising the federation-feed less prominently or closing sign-ups. Now why should instances do that? Well, because instances want to survive. There can be several live stages observed and if an instance doesn’t manage to reinvent itself and it sees no other option, it will slow down the dying-process by putting on a stricter federation policy.
This means in summary: the big instance is drawing instances to it in terms of its abusive policy, result in a general drift of the instances towards walled gardens or in other words: instance protectionism. Ultimately, this will result in all instances becoming walled gardens and because of network effects, only the biggest one to survive.
3.3. Shared Federation Policies can prevent this process or at least slow it down
This can be solved with a minimal shared federation policy that a certain group of instances agree themselves upon:
There will still be drift towards the big instance:
Which is why they will ultimately acquire the same federation policy and cut themselves off from the rest:
Now, the group with the same policy has in fact embraced the same policy as the big green instance, but internally, they still have a diverse federation policy, which results in a much better position for them. They still get drained off energy, because of network effects, but not as much as before. And the biggest instance in their environment is not acting abusive. And even though to the outside, they are just another walled garden, this is fine, if they still support widely adopted protocol and don’t do EEE, which will be prevented if the policy was defined well and enough of the members actually mean it. Also, if they are bigger than the green instance, they can even gain members form it due to network effects. The green instance will be under pressure to join the federation policy, too.
Of course, you could now observe the new environment separated by the federation policy as well. But if the biggest actor behaves well there, it should work fine.
Here we can make the next observation: the biggest instance should have the most (or at least a generously) open federation behaviour that goes beyond the agreed policy.
Of course, this environment could become very big, but this is not bad here, because the goal is in fact to foster a healthy environment in Fediverse and if that environment is healthy, it will allow new instances to join and grow. And if it turns from healthy to unhealthy, instances will leave it and join a healthier environment based on the strategy defined in the second next section.
This means the focus now shifts from instances to environments and the goal of the strategy should be to ensure a healthy, prosperous environment, which by its nature, wouldn’t do EEE or else fall apart, because there would be too much resistance by its members. And it wouldn’t be bad if this would make up the majority of the future Fediverse, in fact, it could even be considered healthy and the ideal state that we should thrive for.
The strategy of the next sections should be able to sustain such a healthy environment and help healthy, federated instances/environments to grow and even softly dominate the Fediverse, such that the emergence of an abusive instance is permanently prevented. This would not mean the implementation of a monopoly: it would be a system that tries to prevent a monopoly in itself.
Now if environments would also become the main subject of our observations, we would need to define them; however, we can just state that all environments are also instances, just with more complex insides and a higher health state. Instances, which practice EEE have very bad health state. This way, not much changes about the observations.
4. How could the ideal Instance Environment look like that prevents abusive Instances from becoming too big?
How would this ideal environment look like? Well, it would consist of instances that uphold what I call “Principles of Fair Federation” as a shared federation policy. What these principles exactly look like will probably be something that will come over time and maybe even change dynamically over time. Hopefully, federation can help us out here, because it will hopefully naturally find the best shared federation policy and a good handle against Threads. If then enough of the instances mean it and stick to it, they can permanently prevent the emergence of an abusive instance. This would be successful, if many followed them, because else the rule wouldn’t be enforced and would essentially mean nothing. Then, if an instance became abusive, it could be excluded from the environment and would lose members. Here, an abusive instance is not able to gain any footing.
That’s also why it would be good if no instance would be bigger than the two second-biggest instances together, because then, it could perform EEE on its own environment.
The biggest environment of federating instances that based on a common policy works against abusive instance, could be called something like the “Fair Federating Fediverse” or “Fair Federating Open Social Web”, and in the future, this will hopefully be the thing that we commonly associate with the Fediverse/Open Social Web. This would essentially mean the implementation and enforcing of a global, shared policy of Fair Federation, which would make the Fair Federating Fediverse the dominant force in the Fediverse and permanently prevent instances like Threads from becoming abusive.
5. A Strategy to implement and keep in place a global, shared policy of Fair Federation
Now a strategy for an instance would need to work towards the Fair Federating Fediverse by both driving the acknowledgement of instances to principles of Fair Federation and enforcing that they are upheld. This way, the fair federating Fediverse could come into existence and it’s on-living ensured. At the same time, of course, an instance also wants to profit and grow from this fair Fediverse or at least stay healthy, which the strategy should also include.
Additionally, there is the third requirement that concern new instances, which is vital to the health of the Fediverse. Because support of small instances is necessary. First of all, opening up a social network to federation always poses a risk: there is a significant chance on growing the network just as well as loosing members that migrate. Therefore, every instance that federates and applies to a certain policy should be welcomed with open arms and given a chance to grow. On top of that, there needs to be an implicit control on the quality of the Fair Federating Fediverse or else, there will be no innovation and effectively performance of EEE. How could that happen? Well, if the policy gets too strict and no new instances are able to or want to join it, it could be a sign that the environment is performing EEE itself and this should also be included in the policy; for example, because its members don’t want to change. This should also be prevented by the new policy.
Now, we don’t yet have this ideal environment (if it will ever exist) nor an ideal policy, and even if we would have it, it needs to be defended and ensured that it remains intact. That’s why I propose a strategy, that seeks to implement the Fair Federating Fediverse and once established, stabilizes it and ensures its continuation; while also preventing it from becoming abusive itself and allowing healthy competition and renewal.
The requirements to a new strategy would therefore be the following:
- Reduce risk that an instance comes into a position in which it can perform EEE on overall Fediverse (or the environment of the instance).
- Foster instance’s own health thus reducing risk that itself comes into a state of wanting to become abusive and perform EEE.
- Ensure that new instances can realistically join the Fediverse (or the environment of the instance), such that continuous innovation and sustainable growth is ensured.
This leads us to the following strategy to be carried out by each instance like this (called Embrace, Extend, Enforce, in short: “Counter-EEE” / “ƎƎƎ”):
Now does this new strategy comply to the requirements? Let us start at the beginning: does it prevent an instance that wants to do EEE to become powerful enough to do EEE? Yes, because abusive instances would be excluded. For requirement 2: does it also improve the own’s instances health? Yes, it does. And additionally, does it still enable new instances to join the Fediverse? Yes. This is ensured by the new strategy if every instance can join the new policy.
That means, because it meets the requirements, it could be a sensible strategy to ensure a healthy development of the Fediverse and prevent EEE.
6. Practical Implementation and Conclusion
If one now got a reasonable fair federation policy, at least one would have a handle on how Threads would be behaving. One could give them conditions, which need to be upheld or federation is stopped. This would at least give them some room to operate and give us a more credible negotiation ground.
In my opinion this will result in something like the following:
It would also give us a better idea on how to evaluate our relationship to Threads and give these evaluations more credibility. For example, one might say that making federation opt-in for users would not fall under our common agreement of fair federation and that they have a certain amount of time to change it or we de-federate until they implement it. This would give us a much better negotiation ground in the power struggle with Threads.
If we just say: Threads is bad we don’t federate, people will find this hypocritical and just lazy (also think about the fact that still many people don’t know how morally bad Meta can act, https://erinkissane.com/meta-in-myanmar-full-series).
And it gives us a handle on how to counter other big instances that will emerge in the future (and for which the Fedipact will be no sustainable solution).
We should be aware of the fact that we, also, with our behaviour could influence Meta’s behaviour. Defederating from them should be the last option and never permanently.
So little Mastodon and other future Fediverse services are trying to keep giant Threads in place? I think this is not as impossible as it sounds. We need to convince Meta that we have a shared, mutual interest, such that they agree to a policy that ensures sustainable growth for both parties. Because that is also what we need to keep in mind: Meta wants to be the good guy. They don’t want to be the one that overthrew Mastodon. They don’t anymore want to have the societal responsibility that comes with a monopoly. And most importantly: they deeply want the market that the open social web could become to become reality. So, I think we might have some ground to operate against them, and only if they only want to use us to enable their entry to a new growing market.
At the same time, we can already see that Threads will go heavy into instance protectionism if their user growth is at stake, even if it is only minor. Threads seems to fear the powers of interoperability and losing the control over the whole thing. Something like a Fair Federating Fediverse is nothing that Meta wants, because it makes it much more difficult, to push its agendas in it. So, if it feels threatened in any way, it will do go in heavy on instance protectionism.
Whether it will work to nudge Thread’s behaviour to our own liking or not, remains to be seen. There is no guarantee that this will work and will also heavily depend how it is actually carried out, but ƎƎƎ would give us a better handle on how to spot changes of Thread’s behaviour and react accordingly, draw lines and push back if it gets too aggressive. But of course, Threads could also be able to practice divide and conquer; by attracting many instances out of a healthy federation policy and by that slowly destroying it, they could get into a position to practice EEE.
In any case, in the future, big instances like mastodon.social will have special responsibility and need to walk a thin line between open itself too much up towards Threads and being drained off its energy by it; and shutting itself too much off and loosing members because of it. And for that constant power struggle, a lot of time and energy will be needed. With the commercialization of the Fediverse, the Fediverse enters a new stage, which, at least in my opinion, cannot be prevented anymore. This requires a new, general and also more realistic look on things for things like Mastodon instances to adapt to this environmental change and survive.
I already expect that this strategy will not be very popular among certain parts of the Fediverse, because it includes the necessity for growth. However, I think everything else is just unrealistic and naïve by now; and also: different from what is actually currently done by Mastodon. I’m not saying that the Fediverse needs to go with every innovation; but if the social web should become the standard of social networks (which I think would be good for the world), we need to face the new realities of it the Fediverse, too, and that’s: either adapt and shape the future, or get extinct.
Eugen Rochko has already realized this (while being generally positive of Threads joining, he was very critical about making federation opt-in on their user side and said so); he is hoping to grow Mastodon’s user based significantly and without explicitly stating it, he is already driving something like ƎƎƎ for a while. Also, there seems to exist for him and many other people already the idea of something like the Fair Federating Fediverse, it is at this moment just still called the Fediverse. For example, after the research by scientists of Stanford university found that Mastodon has a problem with CSAM content, Eugen replied that this was only found on instances that he doesn’t consider “part of the Fediverse”. So, there is a different between instances of the Fediverse that act according to some principles and the rest of the Fediverse, which will become only more apparent in the next time, when the Fediverse will become something like the WWW, on which no one can take anyone responsible for the thing as a whole.
So basically, it’s already implemented, but it certainly can be improved and should be openly debated before the actual arrival of Threads and everything that will follow.
PS: If you like to think in games, Go has the perfect mindset for this struggle with Threads (at least as long as it has the upper hand like currently): no need to completely crush the opponent, just get more of the overall territory 😊
PPS: I wrote this text with too little knowledge of the ongoing debate around it, but after doing some reading, I noticed that my argumentation falls in line with what Evan Prodromou calls a “Big Fedi” mindset although, as I explained, I think of it as a critical and very dynamic approach and not just “Go Meta, go”. Generally, there are some great posts on the Threads-Issue out there, for example: https://evanp.me/2023/12/26/big-fedi-small-fedi/?ref=privacy.thenexus.today, https://www.timothychambers.net/2023/06/23/project-and-the.html? or https://erinkissane.com/untangling-threads?ref=privacy.thenexus.today. The latter by Erin Kissane is a very broad post on the subject that goes way beyond my post and already includes federation policies and a call to enforce them; but what I think I extended is a call to collaborate on these policies. Because I think that they should be negotiated also between federating instances and much more openly discussed in the Fediverse to find a common ground against Meta and get a sense of “unity” among “big fedi” instances. I think big fedi instances that have come to terms over a shared federation policy could be a good ground for the Fair Federating Fediverse to come into existence.
PPPS: I know that I don’t have any numbers to justify my observations, but we may not have enough time to wait for that. I still hope they can be helpful.
Fungiverse Tales 