There's a common false dichotomy about #Threads: cut them off, or leave it to user choice.
I can't speak to other software, but Mastodon offers a third option: limiting Threads. This can be done for all users of a server.
- You can follow Threads accounts after clicking through a warning.
- You have to manually approve followers _from_ Threads.
Note, however, that boosted posts will continue to appear in your home timeline:
https://github.com/mastodon/mastodon/issues/26301#issuecomment-1868240966
I like that option for our server, social.coop, and it's the one we voted to implement earlier this year.
We know that Threads already hosts bad actors (e.g., LibsOfTikTok). We know some reasonable folks have set up shop there and will continue to flee there from X.
This option makes it clear that Threads is not a safe space, while allowing limited connections.
Every instance will implement the option that makes sense to them, of course.
@eloquence can you explain how you have implemented this limiting exactly? #mastoAdmin #selfhosting #selfhosted
If you're an admin, it's done on the "New domain blocks" page (/admin/domain_blocks/new). See https://docs.joinmastodon.org/admin/moderation/#server-wide-moderation
@eloquence but the real reason for future mass migration WILL still be the one that instigated mastodon (long may it exist!) drove the many here, the like minded if I can put it on the table?
@eloquence I've been pretty critical about moderators (particularly of large instances with thousands of users) blocking Threads pre-emptively; but I can get behind this.
My whole issue is that individuals should be able to communicate with Threads users if they want to. This seems to allow instances to adhere to their moderation desires while also not being draconian to their entire user base.
@andrew@melder.social @eloquence@social.coop It's baffling to me that "Hey, ban Threads or else" stances are a thing. There are also admins who will defederate your instance or block you if you federate with Threads.
The entire decentralization thing is about giving user more choices and power and this seems opposite of that. "Let's have only us admins decide and move a bit more towards centralizing ban-lists, what can go wrong?"
Also the argument of "Well, we don't ban you outright, you can always go to another server!" is that it's incredibly inconvenient to do so.
@eloquence It looks interesting that server. I will look more on social.coop and maybe ask for join in
@eloquence Is this the "silence" option? I've been wondering if that is the correct middle ground. I haven't used it on any instances to date so I'm not sure what the practical effect is.
@eloquence yeah, I expect many of the instances who federate with Threads will limit them. From a privacy perspective though, it doesn't do anything to stop people's data from getting to Threads unless they opt out by individiually blocking Threads. "The fediverse is about consent" except when it isn't (opt-out is not affirmative consent).
@thenexusofprivacy @eloquence
Hmm? Doesn't it do about the same amount to stop people's data getting to Threads?
Instance-limit stops Threads users following you without consent. Individually blocking Threads rejects them automatically, instead of manually.
*Neither* is documented as stopping Threads users from reading your posts. Even if authorized fetch is enabled.[1]
[1] I base this on https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/
@thenexusofprivacy @eloquence
Clearly the Fediverse is not designed with consent at the forefront.
You can theorize about taking back privacy on public networks.
But if site A wants to allow Google, and you want to post a publicly readable reply on site A, my hope would be that you're educated and supported in knowing that you'll be Google-able.
E.g. if y'all want to roll back Google, that's a long-standing fracture. It needs work on *clear expectations* or you'll have nothing but fractures.
It's certainly true that the fedierse wasn't designed with consent at the forefront. But you're wrong about the effect of blockig and authorized fetch: sites that block Threads and turn on authorized fetch won't federate data to Threads.
It's true that Threads could technically still scrape public data if they want (and if other actions aren't taken to prevent them) but EU datra protection commissioners have warned them that scraping without consent is non-consensual access to data. And, data like followers-only posts and direct messages *isn't* public so isn't easily scrapable.
> sites that block Threads and turn on authorized fetch won't federate data to Threads
I agree.
> I expect many of the instances who federate with Threads will limit them. From a privacy perspective though, it doesn't do anything to stop people's data from getting to Threads unless they opt out by individiually blocking Threads.
If a user blocks threads.net, their post can be boosted by a different user, and then re-boosted by a threads.net user. Can't it?
@sourcejedi there was just a long discussion about this on my personal account. It turns out that for user-level blocks it also depends on whether authorized fetch is enabled. https://indieweb.social/@jdp23/111597265293660428
@thenexusofprivacy
Got it! Sorry for my failed "clarification".
@sourcejedi no need to apologize, it's a confusing situation -- in fact in that other thread, when I read the documentation I thought the same thing.
@eloquence If there is nothing in the federated timeline from threads, then where/how is "discovery" handled?
In general, "limiting" is bad for discovery - you won't see such accounts unless you explicitly search for them & follow them. Even then it gives you a warning you have to click through.
mastodon.social (the server you're on) has chosen to neither limit nor suspend, so you won't encounter those issues there.
@eloquence This can't be done at the user level, right?
Not as far as I know.
@eloquence That reeks of half-measures.
Then it's probably not the right choice for you, and that's fine. :)
@eloquence would regular & normal current users be connected in any way via a 3rd party and steal data & posts via a rogue "Zack" agent?
It looks to me like just another way to increase data input? Where is his & his employees evil mind's going?
@PabloMartini @eloquence the way activitypub works, there's literally no way to prevent scraping of non private posts.
@eloquence I really don't care for the manual effort. Just cut the cancer off
Totally understand that choice. If you stay on mastodon.social, you'll likely have to do that via an individual domain block, as they have no plans to either limit or suspend all of Threads, as far as I know.
@eloquence I totally agree with you. Mastodon gives a lot of options to its users, if users want they can block accounts they do not want to see.
@ZillaMon if it is not enough for you and you want to have full control, just host your own ActivityPub. It does not take much, only an old computer, internet connection and domain. Then choose what instance you want to run.
So you don't need to "care" the others who are also in the same instance as you.
@aku @eloquence I can also chose to stay where I am and block as I please. That is also an option lest you forget
@ZillaMon @eloquence of course everything is up to you
@ZillaMon @aku @eloquence It’s an option *they literally mention in the post to which you are replying*.
@Voline @aku @eloquence move along I did not ask you for your perspectives and I suggest that you brush up on syntax. *literally
This sounds a good option.
@eloquence The reason we need to block threads at instance level is to prevent users/Meta itself from data collecting and harassment
I agree that suspending is the most effective solution against data making its way to Threads via ActivityPub.
Can you say more about the harassment cases you're thinking about? Limiting does seem to go a long way to mitigate that concern, no?
@eloquence@social.coop even limited they still have your data.
@eloquence Okay, that's a good technical solution but what do you recommend for the constant vomiting?
That legitimately made me laugh out loud. Well played, sir.
@eloquence Glad to hear it.
@eloquence I quite like that option, thanks for sharing this information.
@eloquence Wait can it be done currently? Or could it be done, theoretically?
I mean, can I setup my instance this way? I just want a hop, some friction.
Also, we should name our approaches. It's not that we will all chose one. But it would be nice to say "we're adopting approach so-and-so from so-and-so" so others know.
@eloquence post and replies that might interest @IvanLeFou about the connection between masto and thread.
If someone can link more in depth articles about how thread can be a threat to mastodon, it would be very welcome.
@Holi @eloquence @IvanLeFou You might find this https://erinkissane.com/untangling-threads useful for more thinking around the issue
@Holi @eloquence @IvanLeFou This is thoughtful and includes important evidence : https://mas.to/@kissane/111620930081617737
@eloquence
The gatekeeping is nuts here
People talk about how ActivityPub and open SocialProtocols are the future and wish for them to be implemented everywhere, only then for when it actually happens to cut off those people like a disease...
Really sad to see, imagine the backlash we would give Threads if they were doing this
@zav_ What is wrong with people (either individually or via their admins) deciding not to interact with meta?
Saying everyone must interact or be branded hypocrites feels problematic!
@krnlg I'm 100% for people deciding that for themselves. But that option exists already, you can just block the instance?
The call for admins of instances to server block threads is just gatekeeping
@zav_ But Mastodon instances already block various other servers when they are known for bad moderation and tolerating Nazis and so forth, to varying degrees of tolerance.
@zav_ I think the only realistic way servers can have any rules is by restricting federation when other servers have wildly different rules. Otherwise they'd be flooded with Nazis and lacking the mods to individually block them. Users are free to move to servers that federate with the groups they want to interact with
@krnlg But threads is not known fir bad moderation yet, rn the incentive to block them is just because "meta bad" we havent given them a chance in this space yet
Also the difference is these currently blocked servers have about 10k users with 10% being bad actorsc while Threads has 100 Million + users with 0.5% being bad actors
@zav_ @eloquence While I agree that some instances are way too gatekeepy (mastodon.art is a prime example), not federating with Meta is not about gatekeeping, but about preservation.
Meta is not joining to "expand possibilities for their users" or to give choice. Nothing of that fits in their business model.
What they hope to achieve is only left to speculations, but every possible way that they do business makes it clear that this is NOT going to be good for fediverse.
You illustrate how current servers can limit Meta, but forget that Meta can also defederate, and use this as a tool to control.
You don't think they will? You don't think that can be a severe blow to many servers unless other servers band together against this?
@eloquence Cannot agree more! Saying this as: a refugee from Meta, who withdrew from privacy abuse and non-transparency but...
still wants to benefit from fast technology progress and...
who seeks social integration with diverse people - not just biased bubble of specific to bit hermetic mastodon (mostly leftist or geek)
@eloquence while many people like this option, and I personally think it is the best way to navigate it in the near term, I’ve still been accused of supporting genocide, being friends with Zuck, taking paychecks from Meta to kill the fediverse, and so on. I hope you are having a better go of it.
@jerry @eloquence Sheesh! It is not easy being an admin of an instance!
@jerry @darnell @eloquence it ain’t easy out here in the Fediverse being an Instance Admin.
Support your Admins $$$
Do administrators and moderators in the #Fediverse have support groups? Morale matters.
@jerry @eloquence I love it when they come at me like that. The unreasonable are always the easiest to disarm. It's the ones that come at me cool and calm with salient points that are the scary ones.