Request for Comments: Twitter/X Bridges on social.coop

There are some carefully curated bridge sites, notably https://press.coop/

So a blanket ban may be a bit strong—some folks appear to be doing some attempts to bridge responsibly. And I’m not sure how Twitter bridges are conceptually worse than, say, RSS bridges, given that there is no moderation of RSS and plenty of harassing/terrible websites that publish RSS.

But certainly most of them are confusing garbage, as you say. So a reasonable default might be to limit or suspend.

As I understand it, press.coop is now just RSS feed content (the above content preview notwithstanding). From their "About" page:

This project started as a mirror of popular Twitter news accounts, but Twitter has removed access to the APIs we used. We are using the Twitter profile and banner images to assist users in understanding the RSS feed source

Every account I've clicked, even ones with "tweets" in the name, links to an RSS feed. That said, I agree that if there are Twitter/X bridges that are more selective and that don't let you follow hate accounts, that's a different story and we should be explicit about that in any decision.

In favor of limiting the twitter bridges. Mildly oppose defederation

to get it out of the way: i think what twitter has become is vile, and I don't use it anymore. I also don't personally use the twitter bridges or follow accounts on there bc i think boosting bird dot makeup is cringe and i still have a twitter account to see tweets.

I think in general treating bridges as if they were just another instance sort of misses important subtlety - both in terms of potential uses and potential abuses. There are a few distinctions I think are important to evaluate w/ instance-level moderation, two seem relevant here:

a) moderation of behavior vs. content, and

b) ability to access something vs. ability to say something

Since the bridges are one-way, I think a great deal of the potential harm from twitter user behavior is off the table, as is potential harm from platform capture, etc. that we were discussing w.r.t threads. So this would be purely a content ban, no? W.r.t content moderation i think it is relatively important that members are able to access even highly objectionable and noxious content (with the appropriate caveats) even if we shouldn't allow members to say or repeat that content. eg. I think it's tremendously important to be able to keep appraised of what the fascists are doing and saying precisely because that information is necessary to act against them, but I would be dead-set against allowing members to repeat any of that garbage except behind a c/w and with the clear intent of criticism.

This is especially true given that twitter is now a walled garden that requires login to read. Bridges are one of the few ways of being able to actually see a tweet, and as much as I hate it, twitter still is one of the major places where public information gets shared.

Cutting this off before i get too longwinded: I think limiting is the right balance of limiting incidental contact, but also allows people who for legitimate purposes want to be able to access content from twitter to do so. Defederating doesn't serve to protect members from violent behavior in this case, and I think we should always be cautious about limiting members ability to access information. If the thing we don't like is boosting objectionable content from the bridges, that's already against CoC, and if someone doesn't want to see any tweets in their search results I think they should personally suspend those instances. If we want to make that site-wide then we can just change the `searchable` scope to be `without_silenced` rather than `without_suspended` for a zero-maintenance fix.

that said if people decide defederation is better i won't fight it, like i said i personally don't use them but know ppl who are truly trying to avoid even visiting the twitter domain who do as their main way of seeing twitter posts when needed.

@jonny I think the distinction between content vs. behavior is well-made and I suspect may persuade others towards the "limiting" position. One concern I have about "limiting" only is that it doesn't do anything about these bridges frankly gumming up profile searches (separate from the content search issue). Again, try the "Jimmy Wales" example profile search to see what I mean.

One option that might be worth considering is to "bless" one bridge as the one we support (we could even run our own, I suppose), and to suspend the others.

@Erik Moeller hoping this replies in thread not in main.

I will continue my long held argument that social.coop should run its own fork. After doing it for a year (off of glitch-soc, so a fork of a fork) I can attest that it is actually easy and cool to do. Being able to break out of our options as dictated by base masto and actually propose how we would want things to work without that as a constraint would be a welcome change. Modifying the search indexing behavior is not all that hard, and there are a handful of ways we can do it in this case, if we can reach some consensus thats what we wanna do.

Wish I could c/w a semi-tangent on loomio lmao

I am in favour of limiting Twitter/X bridges rather than suspending as some content important to some users may only be available on Twitter and bridges then enable them to leave Twitter and use Mastodon (part of the interoperability hacks that Cory Doctorow talks about). It is not native Mastodon/fediverse content though so I don' think it should show up in the federated timeline etc. Obviously if someone boosts some horrible content that came via a bridge then the normal moderation policies would apply. However, since members would have to actively seek it out, that seems unlikely to be a regular problem.

With my moderators hat on I'm tempted to approach this the same way as any other server. Bridges effectively make Twitter just another fediverse node, and if any other place were allowing such vile hate speech we'd just defederate. That being said, Twitter is also obviously not like every other fediverse server for several reasons.

The first is its size: We had a similar discussion when mastodon.social was allowing open registration and having a spam problem: normally we'd just defederate to protect our users, but we wind up with the "too big to fail" problem where there were lots of people following lots of accounts on that server that aren't part of the problem, so if we defederate we hurt them (both our users and the users of mastodon.social who can no longer follow and talk to us, and that would be a tragedy, we're pretty great!)

There is also another way in which Twitter is different from other fediverse nodes: the accounts can't reply or read comments from our users (this is technically possible, but as far as I'm aware all bridges are 1 way and read-only). This limits the potential for abuse because there can't be spam attacks, twitter trolls, etc. attacking social.coop members, so banning the entire service is less necessary. Individual hate speech accounts like the one used as an example above can be banned individually to remove their content from the federated timeline (and it's not likely we'll see much of it anyways because it's unlikely that people on this server will follow the specific account).

Finally, if we do decide to ban them, we should make it clear in the language that this is for generic Twitter bridges that mirror all accounts. Individuals still may wish to mirror their own account or several currated accounts like the press.coop example given in another comment with a bot or what not and that's a different thing.

Quick follow up, though perhaps this is obvious: if we decide not to ban/limit Twitter bridges, this does not of course prevent us in any way from banning/limiting individual Twitter users on those bridges. It does result in the problem where they can still be accessed from different bridges and we have duplicates of those users that we have to handle. It's a bit of a mess.

Does limiting solve the search results issue as well? Or does it only filter the federated timeline?

@Brecht Savelkoul I believe this would stop results from appearing in search as well.