Agreed that there isn’t one particular model that’s right or wrong for everybody, and that a split is likely – a region like today’s fedi and that welcomes Threads, and a more safety-focused region (with more blocking, a more consent-based federation).

And, it gives cops another excuse to overpolice Black and brown neighborhoods.

There have been other waves, it’s just that once they get shut down everybody loses interest and moves on. The PR for the one of the changes Mastodon just made was implemented in May 2023 after the Doge spam wave. And here’s a June 2019 post talking about exactly the same kind of attack: “The problem we are experiencing is the spammer signing up on random open instances and sending spam remotely.”

A very good idea! https://startrek.website/ took this approach, it’d be intersting to check in with them to see what they learned.

I had shared the draft version here a few weeks ago, and this incorporates some of the feedback – including “This goes against everything the Fediverse stands for” 😎

Yep. But, even though I didn’t suggest it, I didn’t explicitly say that it didn’t mean global blocklists. So I clarified it, and added a footnote with more detial.

As Instance-level federation decisions reflect norms, policies, interpretations, and (sometimes) strategy discusses, opinions differ on the definition of “bad actor.” So the best approach is probably going to present the admin of a new instance with a range of recommendations to choose between based on their preference. Software platforms should provide an initial vetted list (along with enough information for a new admin to do something sensible), and hosting companies and third-party recommenders should also be able provide alternatives.

Yes, at least on Lemmy. It’s the icon with two boxes.

No, as the article says at the very beginning, it’s that I think a big reason that fediverse isn’t growing is its failure to deal with safety.

Nonsense. Instance blocklists are used across the fediverse today. They’re certainly not a perfect solution but they have the advantage of actually existing. See Blocklists in the fediverse for a lot more discussion.

Fediblockhole does something along those lines for on Mastodon … not sure if there’s an equivlaent in the Lemmy world.

Politico is known for its bias, but I’d say this is a fairly accurate article – Alfred is an outstanding reporter. But you’re certainly right, this is an issue that cuts across party lines.

They don’t, at least not from your instance.

I can’t speak for others but yes, I want a fediverse that doesn’t have white supremacists and fascists.

Indeed, the entire point is that instances should decide for themselves – I say it multiple times in the article and I say it in the excerpt. If they think that you federating with Meta puts them at risk, then they should defederate. And yes, it says more about the instances making the decisions than it does about Meta – Meta’s hosting hate groups and white supremacists whether or not people defederate or transitively defederate.

It’s good feedback, thanks – I thought I had enough of explanation in the article but maybe I should put in more. Blocking Threads keeps Threads userws from being able to directly interact with you, but it doesn’t prevent indirect interactions: people on servers following quoting or replying to Threads posts, causing toxicity on your feeds (often called “second-hand smoke”); hate groups on Threads encouragiingtheir followers in the fediverse to harass people; and for people who have stalkers or are being targeted by hate groups Threads, replies to your posts by people who have followers on Threads going there and revealing information.

And complement the FediBlock tag with FediBacon! It’s got success written all over it!

Very much agreed that part of the problem relates to scale – and, great analogy! It’s an interesting thought experiment: if each school had an Lemmy instance, how would they work together to host communities and make it easy for people (in all the schools) to find the communities they’re interested in? If they each had a Mastodon instance, how would they share blocklists? And so on.

And great point about the different dynamics between large instances and smaller / more focused instances. There’s always a question of which communities an instance sees itself as in service to – and similarly there’s always a question of which instances and communities the team developing the software is in service to.

Thanks, I didn’t know that – I’ll update the post!

Not yet, as far as I know, although there are some groups of instances whose admins and mods have a shared chat room and cooperated on blocklists which has some of these aspects.

A website like that would be very helpful. A lot of people I talk to think that unlisted gives more protection than it actually does (they’re used to how it behaves on YouTube where it’s harder to discover), don’t realize that it’s still likely to get indexed by Googe et al even if they haven’t opted in to search engines (because their post may well appear in a thread by somebody who has opted in), don’t understand the limited protection of blocking if authorized fetch isn’t enabled, don’t realized that RSS leaves everything open etc.

Yes, I think in terms of protecting data generally, not just from Meta but also data brokers, Google, and other data harvesters – as well as stalkers. Meta’s a concrete and timely example so it’s a chance to focus attention and improve privacy protections, both for instances that don’t federate and for instances that do. I agree that most (although not all) of the information Meta can get from federating they already can by scraping and they certainly could scrape (and quite possibly are already scraping) most if not all profiles and public and unlisted posts on most instances, and so could everybody else … it’s a great opportunity to make progress on this. https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/ has more about how I look at it.

Specifically in terms of data that flows to Threads through federating that isn’t otherwise easily scrapable today, three specific examples I know of are

• followers-only posts for people who have followers on Threads, or who have approve followers turned off
• some unlisted posts from people who have opted out of discovery and search engine indexing that aren’t visible today (i.e. haven’t been interacted with via a boost or reply by somebody who has opted in). it’s very hard to predict how many of these there are; it’s not just posts that are boosted by somebody who has followers on threads, it also relates to how replies are retrieved
• identifying information in replies to followers-only posts by people who have followers on Threads. This can flow to Threads even if the original poster has blocked Threads (because blocking information doesn’t get inherited by replies)

That said this isn’t based on a full analysis so there may well be other paths. As far as I know the draft privacy threat model I did last summer is the deepest dive - And the software is buggy enough in general that it wouldn’t surprise me if there are paths that shouldn’t exist.

In terms of concerns about tracking others have about federating … like I say for most people this isn’t the top concern. To the extent it is about data going to Threads, for a lot of people it’s about consent and/or risk management, full stop. They do not want to give Meta or accounts on Threads easy access to data from their fediverse account, even if Meta can get it without consent now (and even if they have some other Meta accounts). There’s also a lot of “well Eugen said it’s all fine”, and especially from techies a lot of “well they can scrape it all anyhow, whatever” and “everything is public anyhow on social networks”.