We have 2-3 months to compile a Threads block list
We have 2-3 months to compile a Threads block list
With the upcoming #meta #Project92 Fediverse service, there has been a, well, robust discussion of how to avoid threats looming. Those advocating mass-preemptive defederation make three cases for it. ➡️ To avoid data mining … However, defederation does virtually zero to avoid any big tech entity scr...
It is expected to be 2-3 months before Threads is ready to federate (see link). There will, inevitably, be five different reactions from instances:
-
Federate regardless (mostly the toxic instances everyone else blocks)
-
Federate with extreme caution and good preparation (some instances with the resources and remit from their users)
-
Defederate (wait and see)
-
Defederate with the intention of staying defederated
-
Defederate with all Threads-federated instances too
It's all good. Instances should do what works best for them and people should make their home with the instances that have the moderation policies they want.
In the interests of instances which choose options 2 or 3, perhaps we could start to build a pre-emptive block list for known bad actors on Threads?
I'm not on it but I think a fair few people are? And there are various commentaries which name some of the obvious offenders.
You're viewing a single thread.
Only real threats of Threads federation are EEE and server overload. Not the people from there or privacy. If someone wants to see some content you don't want to see, like some opinion you don't like, they should be able to see it. I don't understand why there would be such list, it would be pure censorship and waste of time. I have heard Threads has a pretty good moderation, so that solves this problem anyway.
I don't get what would defederating with Facebook-federated instances gives you, though.
I don’t understand why there would be such list, it would be pure censorship and waste of time.
A major point of the Fediverse is that you can choose instances based on their moderation policies. If you want fash crawling your timeline, join an instance which allows fash to crawl your timeline.
I don't get what would defederating with Facebook-federated instances gives you, though.
Site A hosts communities that serve vulnerable people. They see Meta as a threat to those vulnerable communities, as they are not well moderated, and have no issues with hate speech and harassment, so they defederate.
Site B federates with both Site A and Meta. They act as a pass-through for content from Site A to reach Threads.
Bad actors on Threads see content from vulnerable people on Site A and engage with it. People from Site A cannot see the bad actors on Threads doing this, but people on Site B do, and bad actors there get alerted to an opportunity to be proper shit stains. Now, vulnerable people on Site A get targeted by this induced harassment coming from Site B.
What does Site A do?
They defederate from Site B.
The question is just about whether they wait until the harm has been done or not.
Defederation is a one-way block of incoming traffic from the blocked instance. I'm on lemmy.world and can still see Beehaw content posted by Beehaw users even though they've defederated from lemmy.world, but if I comment on that content it will only be visible to lemmy.world users. Beehaw has protected its communities from lemmy.world commenters, but its content is still accessible by anyone for any purpose. Instances that federate with both sides don't change this.
I'm looking at beehaw communities on both Lemmy.world and Beehaw.org,and they're totally out of sync with each other. There's the rare post from a beehaw user that breaks through somehow - possibly boosted from a kbin or Mastodon instance? - but for the most part, you're getting basically none of the content from those communities.
Because beehaw isn't sending you any updates.
Is it that you're seeing beehaw users who are posting to communities hosted on 3rd party communities? Because that's absolutely possible.
And that's absolutely the issue with federating with sites that continue to federate with instances you've defederated from. You're blocking direct communication in both directions, but there's a lot of indirect communication going on.
Like, this is literally the scenario I described.
No, Beehaw users posting in Beehaw communities visible on Lemmy.world. There's no third party interaction on either of those posts (just the Beehaw OP and Lemmy.world comments). Whether or not Beehaw is doing the convenience of sending updates, their content is accessible through Lemmy.world. It might take some action on a user here to trigger a pull, but it's entirely possible and you shouldn't expect defederation to prevent an intrusive instance from continuing to get content if they want it.
I don't know for sure there isn't some pathway through another instance causing this, but in my understanding that's not how federated communities work. There's the owner instance that has the true version of the content and distributes it around and then local copies on each other server that feed their updates back to the main instance. You wouldn't ever take a third party's version of a community because you couldn't trust its legitimacy.
I don't get what would defederating with Facebook-federated instances gives you, though.
Means the instance isn't part of the hive mind and we obviously can't have that!
I am a fediverse enthusiast and I am excited for Threads federating. I hope it incentivises Tumblr to federate also and then we actually finally have proper choice.
I see you're not familiar with EEE. This is a classic move by enterprise to kill an open competitor.
I am. How could they kill the fediverse? If they tried to kill it, it would only return to how things was. Chances are tumblr could join in and then they couldn't easily extinguish it.
Ever heard of XMPP?
If a single party participating in an open standard is large enough, they can go off the track, and then kill off interoperability.
The XMPP history going around Lemmy lately is kind of exaggerated.
It's blatantly wrong. Google extended XMPP for their own purposes and when participating with XMPP no longer suited them, they left. The collapse of the "XMPP userbase" is a misnomer - those users were never XMPP users. They were Google Chat users. When Google left, XMPP was in the same state it was in before Google got on board. It returned to its status as a niche protocol for a service that, as @effingjoe@kbin.social points out, people didn't really want anymore.
I completely agree with this take!
So is this suggesting we need more instances?
I feel like people read a comment that linked XMPP with EEE and keep parroting it while not understanding it.
XMPP still exists, but people largely don't want "Instant Messaging" anymore. They don't want to care about whether the person is online before they can send a message.
Google dropping support for XMPP didn't do that, it's what caused them to drop it. They moved on to what people wanted: asynchronous messaging.
This concern about the now overused "EEE" stuff is blown away out of proportion.
But this isn't a single party. Mastodon and Lemmy and Kbin are well established
They're well-established now. A behemoth like Meta entering upends everything. Especially if they gain traction over the next year.