As a moderator of a Lemmy instance, you currently have two options to take: pushing users first to your local content or content from all instances you federate with. These options come with the costs seen in the picture. The moderator of another instance has the same choice. However, in this scenario, they will both always switch to promoting the local-feed. I don't want to say its wrong - it's just the most sensible way to act on Lemmy currently. However, if everybody does it, it is bad for the overall discussion quality of the Threadiverse.
Its a classical prisoner's dilemma from game theory, which sometimes happen in society, for example with supply shortage during lockdowns. A way to solve it is by making action B more positive and option A more negative. This would lead to more moderators choosing Action B over A.
Mastodon solved this with an Explore-Feed, which consolidates the Local- and All-Feed. I think this could also be a solution for Lemmy. It would result in less engagement decrease AND an overall positive effect on discussion quality.
Additionally, a general acknowledgement that instance protectionism is a problem and should be avoided could help to make A more negative. In other words: increasing the pressure by the community. This would put a negative social effect on option A. So: start talking about it with your moderators.
Do you think these two measure would do (additionally to more powerful moderation tools, which would only enable a working explore-feed in the first place)? Is this a problem on other services on the Fediverse too (at least Mastodon seems to have handled it quite well)?
Remember, there's no revenue to compete over here. Analyses that depend on standard capitalist competition should be expected to not only be inaccurate here, but incoherent. They simply don't describe the actual incentives for people's behavior.
From a game theory perspective: You have no reason to believe that this specific payoff matrix actually describes the situation here. There are lots of other games besides the Prisoners Dilemma. Are you really sure you're not looking at a Stag Hunt, or a Battle of the Sexes (terrible name, but that's what the papers call it)?
Maybe, but its just a model. You need to be more specific. I want at least a counter-example ;)
Oh, I think you are right. Stag Hunt does fit better ... But I think it doesn't change anything about the overall argumentation (I think I actually accidentally used the numbers of stag hunt in the picture)
it seems you’re being excessively critical of the defining feature of the software.
you can go back to reddit if that software meets your needs better.
changing the federated nature of lemmy et al would just make it a different product. that product already exists and you left it for this one.
it’s like you quit the police force to join the firefighters and keep telling the other firefighters they should be stopping more crime instead of fighting fires.
I'm all in for federation. Thats what I'm actually trying to improve
Where am I critical of the underlying software?
Oh, shit, I actually got the numbers wrong. For the prisoners dilemma, it should be (-1, -1) in the bottom-right corner
Here are the updated versions.
This one is if you look at one moment in time:
This one includes future development of the Threadiverse and the consequence of the action for that:
The second one isn't prioners dilemma but battle of the sexes (yeah really dump name). I removed the All-Feed option, because for smaller instances it has really no merit to promote it (why should you promote a feed, in which your instances is effectively never present and therefore just drains away your user engagement to other instances?).
As @recursive_recursion@programming.dev suggested, this would resemble the infinite prisoner’s dilemma and models the overall situation better.
The explore-feed here is simply to put a probablity on local and all-posts. So its a feed that randomly picks post from local or all. Let's say you get three out of four posts from all federated instances and one from your local instance. This would direct user engagment to the threadiverse but not drain an instances user engagement all together (especially for smaller instances).