hey everyone on gamedev.lgbt 👋
everybody knows that other platforms like Threads and Bluesky are inevitably going to join the fediverse. Servers have been debating on how to interact with these new instances.
I've done a vote on this before, but I would like to do another one to check the water again.
I've heard about a third option, which is limiting these instances (outlined here https://social.coop/@eloquence/111588877096843391)
So would you… (and please elaborate your thoughts in the comments!)
threads meta
@bram Disclaimer: I am not on your instance.
Something very important that that suggestion doesn't mention, is that limiting an instance in no way prevents people on that instance from seeing *your* users. It only prevents you from automatically seeing *theirs*.
Given that one of the major problems with Facebook is the large crowd of folks actively looking for eg. queer folks to harass (like aforementioned LibsOfTikTok), that means that limiting them isn't sufficient to prevent these issues, and that is very likely why other instances have not considered this option - it's not a forgotten third option, just one already considered and found ineffective.
(I also find the wording of 'quarantine' to be a significant overpromising of what limiting actually does. Limiting a server isn't useless, but it also doesn't do that much useful either.)
re: threads meta
@NervousGamedev I'm not certain that that actually works as it should (considering the issues around eg. AUTHORIZED_FETCH), but more importantly, that means that every single user is exposed to these dangers until they eventually maybe coincidentally learn about the federation with Threads and what that means in practice (which is what instance-level policies are meant to protect from)
re: threads meta
@joepie91 I'm not aware of what those issues are. I'd much prefer if instance admins could set things up so it's an opt-in policy. Maximum protection for everyone by default is great but it'd be nice to be able to follow people from those instances on a case-by-case basis.
re: threads meta
@NervousGamedev Both of these relate to long-standing issues, with Mastodon (the software), unfortunately.
People have long been asking for a "default defederation, opt-in per-user" feature (for exactly this reason), but none has materialized, leaving "blanket defederation" as the unfortunate next best option in the face of a threat like this.
Regarding AUTHORIZED_FETCH: this is the mechanism that, simplified, makes instance A check whether instance B is actually allowed to see its posts before serving them up. This is off by default in Mastodon. Turning it on breaks the entire local web UI since 4.x - as a result, defederation is already shakier than it should be.
This, and the entire history of decisionmaking that led up to this situation, calls into question how robust the different access control mechanisms in Mastodon actually are, despite what Gargron claims. It's one of many poor safety choices in Mastodon.
So I certainly wouldn't assume that 'blocking a domain as a user' hides you from that instance, without first explicitly verifying that in practice and from the code... and that track record of shaky access control is why :/
re: threads meta
@joepie91 So this is a problem with Mastodon specifically, not ActivityPub?
threads meta
@joepie91 Isn't domain blocking a viable way for individuals to opt-out of contact with Threads etc regardless of what the instance admin decides? https://mastodon.social/@Gargron/111587088958531028