Thank you for taking the time to explain it in such simple terms, I've joined a few hous ago and I've been going INSANE trying to find an ultimate-like FAQ about what of this really is.
The Devs are hard at work, there is just a lot for them to do. You can see the most recent PRs here. You can raise an issue here for more visibility: https://codeberg.org/Kbin/kbin-core/issues
Now, I am on the can we ban Threads train, I wasn't at first because they hadn't gotten involved in actually joining the rest of us, now they are and they've admitted they want all our information too, I just don't want any part of that.
Things collected from fediverse participants that interact with Meta users...
- Username
- Profile Picture
- IP Address
- Name of Third Party Service
- Posts from profile
- Post interactions (Follow, Like, Reshare, Mentions)
They've never met a piece of data they didn't want to mine, have they?
I think the implication is that threads/meta is going to use it for different purposes than your average fediverse application/server owner would.
However, it is kind of a silly argument to bring up in the context of fediverse since everything you share publicly online is, well... public info from that point onwards - even more so in the fediverse that by design sends and stores it to countless other, privately owned and maintained, servers beyond your control. This comment is public and any other individual or company can get it whether they do it through activity pub or by just scraping it off any of existing (or their privately owned) instance.
The real risk threads poses is competition and taking away content creators from mastodon, indirectly pushing everyone else under the facebook's corporate umbrella again. I want FOSS to take over but if there's nobody actually using it and everyone is still creating content elsewhere then there's few reasons to stay.
I don't understand the point of this article at all. How would an instance federate without processing these information? (And I think the IP cannot be collected; not sure why the author indicates so without source.)
Not sure if the author understood anything about the fediverse, either. Feels like an AI-generated article, honestly...
The point of the article is to appeal to people's hatred of Meta (which is well-earned, admittedly), not to actually say anything meaningful.
Having observed conversations about Threads here and on Lemmy, it's a pretty dependable tactic. I completely understand not wanting to associate with Meta and not trusting their intentions, but there are plenty of things to criticize them for without trying to whip up a fury over what's objectively not problematic. But this is the internet and people like being in a fury, so whip one up they will.
@BraveSirZaphod Hey, I'm the guy that wrote this. While I absolutely hold negative bias towards Meta, the point of the article was not to produce a piece of propaganda, but instead illustrate that their policies have updated to acknowledge the existence of third-party accounts on other servers, that they will be collecting data, and that this is likely a sign that federation may be happening sooner than expected.
Not everybody is happy about that, and some developers are working on hardening their applications to protect against unauthorized access for edge cases related to this.
I don't think this is a good idea. Keep in mind that different instances have different policies, moderators, and users. This leads to different rule enforcement, culture, and federation status. Even if a magazine/community has the same name and the same discussion topics does not mean it's the same group of people reading those posts (some might be, due to cross-instance federation, but not all will be). In short, they are different groups and cannot be treated as the same without pissing off people.
The proper solution is to let each community just evolve until one naturally emerges over time as the go-to community or they all differentiate themselves enough to be considered different (albeit with similar names). Adding a bot to cross-post content just slows that process down and makes the problem persist for longer. If a topic is truly small enough that getting enough people for critical mass is difficult (like your DIY cobbling example), then it shouldn't be hard to start a discussion in each of the separate communities to suggest assigning one as the "main" one and then just stop using the others. This is something that should be driven by the communities, not the software.
The first one that comes to mind is that defederation DOES stop your posts from going to Meta's platform when combined with the AUTHORIZED_FETCH server setting, while a simple user-level block may not. Depending on your server's settings, your posts may or may not be available on the open web where Meta could scrape the data - but this is still very different from them appearing in the feed or search results of, say, the transphobic, racist, or antisemitic groups that call Meta home.
This has serious implications for user safety and should not be overlooked. In fact, user safety is one of the biggest issues I have seen people mention when advocating for defederation.
Second: it's not yet clear if threads will allow their users to follow people on Lemmy or Kbin servers. But if they do, their users - including, for instance, the millions of followers of some big celebrity or politician - would be able to uprank posts and influence what you end up seeing. You might have LibsOfTikTok tell their users to brigade any posts critical of them, who knows. Meta's own algorithms could end up surfacing certain posts to their users, making the post rankings here largely a reflection of what Meta wants their users to see.
In other words, there's a lot more to the story than just 'blocking their content' when it comes to why you would want full defederation.
Here are a couple of blog posts that go into more detail around some of the data & privacy issues with federation:
Finally someone who has a clue. That was well written and easy to understand. Thank you for all the work you put into that post!
Defederation is about what an instance allows in, not what an instance allows out. Defederation stops you seeing the defederated instance's content, but it does not stop them seeing your instance's content.
As a final, tiny little point of interest - there is a setting called AUTHORIZED_FETCH (Secure mode) which will force the requesting instance to authenticate. This can be used to stop the data from flowing out.
Of course enabling this is somewhat problematic as it tends to break other things. But it's there.
Thank you for the clarification. I was also confused by that quote (ie: if you can control who’s data your reading… you should be able to control who has access to your data. Of course, this doesn’t include mirroring content and other shady practices, but I don’t think Meta would go down that path to avoid being defederated)
Good question! By and large, some of the following would count as a "strike":
Poor moderation
Excessive spam
Most importantly: Making non-backwards compatible changes to the ActivityPub specification that may lead to the classic "Embrace, extend, extinguish" situation
This is utterly baffling and goes against the whole idea of the Fediverse. To take advantage of the impending mass migration, just days before Reddit shuts down their universal API access for good, this all leaves a very bad taste in my mouth.
So users now have to choose between two already-smaller communities when making the transition? This is only going to make a semi-complicated process even more confusing, and end up pushing users back to Reddit.
I had mostly used Lemmy.ml up to this point, but I didn’t leave Reddit to join another u/spez dictatorship. What a disappointing turn of events. Kbin is now my primary.
I'm not sure how much you know about networking or HTTP, but from the evidence posted, this very much is not the kind of thing that just accidentally happens.
fediverse
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.