((I'm not an expert, I've been reading up on things as much as I can. If there's an error, I'll happily correct it!))
TLDR:
- Nearly all of us distrust Meta and have the same broader goals
- We need to pick the best move to go against powerful companies like Meta
- Defederation may not be the right move, and it might even help Meta move forward (and more easily perform EEE)
- There are other options that we can spend our energy on
- It doesn't matter for Lemmy (yet), this is more a conversation for Mastodon, Firefish and Kbin
We've been getting a LOT of posts on this, but the misconceptions make it harder for us to decide what to do. If we're going to try and protect the Fediverse against large, well funded companies like Meta, figuring out the right action is important. We need to actually look at the options, consider the realistic outcomes, and plan around that.
I'm willing to bet around 95% of users on Lemmy and Mastodon CHOSE to be here because we understand the threat Meta/Facebook poses, and we want to do something about it. That's not in question here.
So in that sense, please be kind to the other user you are replying to. The vast majority of us share the same goal here. When we disagree, we disagree on the best path forward and not the goal. Wanting to stay federated DOES NOT mean the user wants to help Meta or thinks that Meta is here for our benefit.
Misconception: Defederation will hinder Meta's EEE
It might, but not necessarily, and it might even help the EEE. Here's a link to some history of EEE, what it means, and some examples: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish. I'd recommend at least skimming it because it's interesting (and because this isn't the only fight)
Assuming Meta is doing an EEE move, they're in the embrace stage. That’s not about us embracing them, it’s about them embracing the protocol, which they can do whether we stay federated or not.
Defederation can tell newcomers that the defederated instance is an island, and they’re better off joining the place where they can talk to their friends and see the content they want. We saw this early during the Reddit exodus with Beehaw, where many users hopped instances away from Beehaw.
Meta can more easily embrace if more people actively use their platform. They can more easily extend if we're not around to explain why extending is a poisonous action. Being federated can allow us to encourage users to ditch Meta’s platform and join an open one (ex. Mastodon, Firefish, etc.)
Misconception: Defederation is the only move
Defederation is the first option that comes to mind. It sounds simple, it is loud and newsworthy, and it can be done with the click of a mouse. But if it is a bad action, then what are the good actions?
- Don't let them have a monopoly over the use of ActivityPub. Grow the other platforms: The extend stage only works when the platform gets a near monopoly over use of the standard. That brings up the first action. If there are enough users, services and resources on things like Mastodon/Lemmy, then Meta (or any other company) can't just extend the spec without causing their users to ditch Threads to stay connected to the content they want to see.
- Reach out to organizations in your area or line of work. Help them join Mastodon or other relevant Fediverse platforms. I'm sure the for-profit companies put money into this process, so brainstorm and reach out
- Add your Fediverse accounts to the bio of your other accounts, and share posts from the Fediverse elsewhere
As long as there is a healthy community away from Meta (ex. what we have right now), then they can't extend & extinguish.
- Protect the Standards and share why it is important
- Share posts from experts about strict adherence to standards, support regulatory and legal advocacy (interoperability requirements etc.), and educate other users about the risks.
(I didn't want to say more here because I'm not an expert, I'm happy to edit more points in)
Misconception: We should still defederate because of Privacy Risks
Not necessarily (and likely not at all?)
Meta is notorious for gathering data and then abusing that data, so this is an issue to consider. However, the way that activitypub works, the outgoing data is publicly available. Defederating with Meta doesn't prevent that, and federating doesn't give them any more data than they could get otherwise.
Misconception: Lemmy instances need to decide
This is a big point: It doesn't really matter for Lemmy right now, one way or another.
It's more of an issue when data starts coming IN to Lemmy from Mastodon and Meta's Threads (or out from Lemmy to Threads). See below
Edit to add: For now it might even be good to defederate from Lemmy as a symbolic gesture. My instance is defederated, and I don't plan on trying to change that. Ultimately it doesn't change much
Legitimate risks from Federation with Meta, and more effective ways to counter them
-
Algorithmic Amplification: Meta's history of using algorithms that prioritize engagement can amplify harmful or divisive content. These algorithms are not public like it is with Mastodon and other FOSS platforms.
-
Misinformation and Content Moderation: All Fediverse platforms will have to work on content moderation and misinformation. Platforms like Meta, focussed on profit and advertising, will likely moderate in a way that protects their income. Those moderation decisions will be federated around.
-
Commercialization and User Exploitation: Meta's for-profit nature means it's incentivized to maximize user engagement, at the expense of our well-being.
-
Additional Data on how the free fediverse interacts with their platform (this one is harder to make a counter for)
Counters:
- Promote user control over their feeds, and develop USEFUL but safe and open algorithms for the feeds
- Flag content and users from risky platforms, with a little warning icon and explanation (ex. 'Content is from a for-profit platform, and it may ___')
- Implement features so that users can opt in or opt out from seeing content from risky platforms. In particular on explore/discover/public feeds, so it doesn't affect content the user is following.
- Develop strict community guidelines that can get Meta (and other companies) sent into the 'blocked by default' bins mentioned above. (edit: There's a good point here that if Meta'a Threads is full of hatred or poor moderation, then blocking them is the right move)
Final point: Evaluate things critically. Don't even just take my word for it. I doubt Meta or other groups care enough about Lemmy yet to spread disinformation here, and every post I've seen promoting defederation feels like a good faith attempt for something they believe in. But it's still worth thinking about what we're supporting.
Sometimes what feels like a good move might not help, and could even make things worse.
I want to throw this into the mix, but something that kept getting ignored early on during the reddit departure was the implications of defederation on how that effects networked systems.
It's part of the math of social graphs, but bad faith instances and teolling, severely impacted Lemmy's initial ability to catch on. By defederaring you massively reduced the total size of the network interactions that take place ( even if it's very important to do so ).
This has the potential to allow meta controlled instances to rapidly out populate non meta controlled instances. From there it's only a matter of time before they end up with a seat on the activity hub team. Then we're back where we started.
Won't the amount of users using meta effectively be a ddos attack on the smaller instances though?
Also, why is meta freaking out so hard about instances defederating if it isn't an issue for them? I haven't seen this much gaslighting since 2015 & 2019 days.
Nope, because Threads users will be visiting Threads, not sh.tijust.works (or mastodon.social or whatever). So even if 10,000,000 Threads accounts decide to follow a single mastodon.social account, that account's instance only syncs it with Threads, not every single user.
Unless I missed something, they're not. I'm pretty sure they haven't commented on the topic whatsoever.
Which could still be millions?
LMAO, I don't think you missed something. There sure are a LOT of people that really want meta here with no benefits listed and only vague reasons why the other is wrong, that sound a lot like sway techniques. There are a few libertarians too, but mostly the first one.
AFAIK, there is only one Threads.net
I hate and don't trust Meta, so the main benefit for me would be the ability to follow Threads users from my nonprofit, ad free, tracker free, Mastodon account I already have. I don't want an account with Meta.
That is the first actual benefit I've seen, lol. I won't be following any threads users, so it wouldn't be a benefit. I also don't know a single soul that is a threads user either.
That's not how it works. When you're federated together, you get a copy of every post on your server. Someone else said that that can be avoided, but I doubt threads will do anything in the other instance's favor unless they get something out of it.
Nope. Only followed accounts (or in Lemmy's case, communities), and only toots (posts) made after the first user starts following it.
Right, we're agreeing. That could still be millions even if the 160 million isn't true.
It could be millions only if hundreds of Mastodon/Lemmy users start following hundreds of different Threads users.
Which I don't think it will be the case, since it seems like Threads federation is going to be opt-in by their users.
If 50 Mastodon users start following 100 Threads users, the impact will be negligible, since Threads will only push messages by those 100 users.
We have over a million users here, it's likely that 100s are going to follow 100s. That's not that many.
sharedInbox handles this.
mastodon.social sends a single federation activity to www.threads.net's sharedInbox. threads's internal systems handle all the visibility and routing to followed users and whatnot. the same thing happens in the opposite direction for threads->mastodon (or whoever).
now in theory this is an optional part of the specification and you can in fact send one activity per person if you really want to, but considering how widespread it is (and how relatively easy it is to implement) you'd have to be intentionally and explicitly malicious to not use a sharedInbox if the remote server indicates it supports it.
You know a lot about the infrastructure of activity pub.
no, not really.
i have attempted to build my own federated stuff (none of them actually federated "in real life" though) so i did read the specs but quite a lot of these are from my memory and if there's anything i know is that my memory fuckin sucks lol
I think you're sincere about wanting to federate. I don't agree at all and I think you're being naive about them trying to take over, there is a shit ton of astroturfing going on in these threads, but wanting the fediverse to grow isn't a bad thing..
I hadn't really considered that. My primary concern was more around 'outvoicing' the non-threads based instances.
Basically, even a tiny fraction of their users being engaged would almost instantaneously be an extinction level event for what would become the "old" fediverse. De-federation early with problematic instances pretty much killed the growth the lemmy could have seen, even though I do agree it was important and necessary. Right now if I go to Top of 1 Hour on Lemmy.world, I only need to go 3-4 pages deep to have seen all the posts from all the federated instances that have been submitted in the past hour. Maybe 100-300 tops. Within that, the total number of comments in this corner of the fediverse is equally low, and I think we're likely in some of the most active regions of the fediverse (although we're kind-of flying blind).
If we assume even 1/10th or 1/100th the rate of engagement comparing a current lemmy user (which I think is not very charitable) to a future threads user, and if we assume we currently have around 70,000 active users (which again, not very charitable), they'll only need 700,000 - 7,000,000 subscriptions to become "most" of the content on the fediverse. This is where the network interactions aspects becomes critical, because they instantly become superconnectedness in graph theory explains much of the emergent phenomena we see around things like post popularity and virality.
Basically, Meta can come in and swamp us with content through pure numbers, and if federated, there is nothing we can do to stop them. Likewise, if not federated, we're relegated to a backwater position in the fediverse; it will become almost impossible for any non-threads based content to find its way to the top. This is fundamental to the math behind how these kinds of networks function. There is nothing you can do to stop it.
I'm not trying to be a pessimist. Like you I'm trying to be a realist about the implications of federating with meta and the considerations and consequences that come along with it. I'm more concerned around the implications when I look at it through a theoretical lens.
I don't know what the answer is, but de-federation seems preferable to extinction.
There is no activity pub team. There is an informal group discussing enhancements at https://socialhub.activitypub.rocks but anybody can join that and submit proposals. Any nobody is required to accept or implement those proposals. I have joined the forum and submitted a proposal myself, but nobody has implemented it or even seems likely to.
Also, not blocking threads doesn't make your instance a "meta controlled instance". Meta has no power over any instance other than Threads. Even instances that don't proactively block Threads can't be forced to use any hypothetical Meta extensions to AP. And its really unlikely that people who started servers on a minuscule network (most likely for fun or philosophical reasons) are going to follow Meta's lead just to have access to more people. Everyone who is here and everyone who started a server here knowingly did that on a network that is a tiny fraction of a percent of the size of other social networks; an increased userbase isn't some big reward for fediverse server admins.