Switch Bluesky to opt out?

[snarfed]

Not actually planned yet, but lots of people regularly request it, so I want a place to capture some of the discussion and ideas.

Norms on Bluesky are different from the fediverse in this regard. Also, unlike the fediverse, Bluesky is a fully public network, with global full text search, and the whole network's data is easily downloadable and accessible. And finally, the team themselves have said that part of being an open network is that they prefer tools and bridges like BF to be opt out.

On the other hand, https://snarfed.org/2024-11-01_53932 . I wouldn't really consider making this change until if/when Bridgy Fed has some kind of real organizational structure, governance, and sustainability, as opposed to now, where it's just one person's side project.

[snarfed]

If this ever happens, we'd need an extremely easy way for Bluesky users to opt out. We already interpret Discourage apps from showing my account to logged-out users as opting out, but we'd probably also want a way that's Bridgy Fed specific, trivial to do, and minimally invasive, ie not a hashtag in profile bio. DMing no or opt out to @ap.brid.gy is one option. OAuthed button on https://fed.brid.gy/ could be another.

[devilspeech]

This would likely alleviate a lot of the friction that opt in has introduced. My experience of trying to ask people to opt in on Bluesky has been like pulling teeth, even if everyone has been fine with it once they know it's an option. Most Bluesky users don't have DMs open since that is the default setting (as opposed to fedi where most people don't bother to turn on the setting that blocks DM notifications) so I am essentially forced to have an account on Bluesky to inform people about the bridge. And even then people often don't seem to understand what to do despite my best efforts to explain it in simple terms... Not to mention language barriers, on the off chance that someone does have DMs open the DM that Bridgy sends is also only in English.

I know it has been discussed ad nauseam, but I hope this could be reevaluated with more perspectives from people who are actually trying to use the bridge now and are running up against these barriers. I have accepted that we just have to live with it on fedi, but it would help us a great deal too if Bluesky didn't have the same artificial restrictions imposed on them.

[snarfed]

Thanks @devilspeech!

One difficulty here is that people often complain and provide feedback when they're unhappy more than when they're happy. I may consistently hear from people right now who want Bridgy Fed to be opt out, but since it's opt in, I may not get a proportionate amount of feedback from people who want it to stay that way.

Not that volume of feedback for or against is the main deciding factor here; just trying to be aware that it may not be representative. Hard to know.

[shiribailem]

Just going to chime in that the norms aren't different, you just got dogpiled by random people who don't know the norms. Typical vocal minority sort of thing because a lot of people who recently joined think the fediverse is some sort of closed secret thing...

[devilspeech]

Exactly, it was clear from the start that the fedi users who demanded to be "opted out" simply didn't understand or were being willfully obtuse about how federation works. The bridge is like any other instance, no data is sent unless users choose to follow each other, and if you don't want to federate you can block the domain at the single click of button. Most of the instances and users who would object to being bridged probably already have the domain blocked anyway, so what functional purpose does opt in even serve for them now? They aren't the ones who have to jump through all the hoops they wanted put in place. All their harassment campaign really accomplished was making it so the rest of the millions of people on these networks who are desperate to maintain their connections are functionally barred from doing so. All because a minority of fedi users were confused and willing to resort to bullying to get what they wanted.

Again, I understand that it's no longer up for debate and at this point it's more about the fact that Bridgy is not critical infrastructure that it has to stay this way. It's just frustrating knowing that it is entirely feasible for Bluesky and fedi to interoperate and if things had only gone slightly differently they would be connected by now. It feels even more important at this point in time when so many people are in the process of trying to move off of other platforms and need all the encouragement they can get.

[Fauli1221]

I personally would recommend to post about this issue on bluesky and try to get as many opinions as possible if there is a big pushback it's a bad idea if there is just a few people who don't want it and most people don't mind or care you can consider it

[Tamschi]

@shiribailem @devilspeech It's not just a minority. You can see this for example by comparing with Flipboard who got mass-defederated recently over bot activity. For technical reasons, Bridgy Fed does have to run a very similar follow-bot to provide a consistent bridging experience from ActivityPub. The main difference is that this one only follows (back) when prompted, which makes it more acceptable to admins.

That said, have a look at #1305. An admin opting their instance in by default is much more technically feasible and shouldn't lead to backlash if it's communicated well, while still removing most of the friction. (In fact Flipboard is doing that already, just with a custom implementation to simulate individual opt-ins towards Bridgy Fed.) Doing it via the ActivityPub Relay mechanism also would mean much lower server load and that we wouldn't need the follow bot to bridge users from that instance consistently (outside of possibly 'Quiet public' replies to bridged posts (see #1036), but it could be better to still use individual opt-in for those anyway).

Before bridging groups of accounts without individual opt-in though (in either direction), I think it's important to have #1406 first. Bluesky does have pretty decent safety tooling now, arguably better than Mastodon, but to use it the bridge accounts need to be able to block anyone on the network.

[devilspeech]

For bridging AT to AP I had assumed that an opt out system would work similarly to bird.makeup where the AP account for the user would only be created when someone searched for that user on their instance, so it would only bridge Bluesky accounts that were followed by real people on the fediverse. I have to imagine the bot wouldn't need to follow every single user on Bluesky in order to have opt out for Bluesky? If being followed by the bot is actually required for fedi users to be searchable on Bluesky at all that's fair, opt in for fedi makes sense then, but if it's possible to have a system where we can just straightforwardly search for and follow Bluesky users on fedi without having to contact every single individual person to get them to opt in to the bridge that would be ideal, in my opinion. Fedi users are typically pretty good at figuring out how to use these kinds of tools if they really want to anyway.

[snarfed]

For bridging AT to AP I had assumed that an opt out system would work similarly to bird.makeup where the AP account for the user would only be created when someone searched for that user on their instance, so it would only bridge Bluesky accounts that were followed by real people on the fediverse. I have to imagine the bot wouldn't need to follow every single user on Bluesky in order to have opt out for Bluesky?

That's right. @Tamschi was talking about the other direction, bridging from fediverse to Bluesky, and how fediverse admins could currently automatically bridge everyone on their instance, ie #1305 .

[Tamschi]

@snarfed was a little faster, but yes that's all accurate.

On fedi/ActivityPub, searching for a Bluesky user with their full bridge handle or JSON-LD @id will "probe" the bridge. We could even return the profile without actually enabling[^1] the bridge for that user yet, and do so only when someone follows. It's not necessary to follow someone to observe their activity on ATProto, so the bridge itself can be passive there. (I wonder if we can see who performs the lookup, but I suspect in many cases the profile fetch will be signed by the instance actor instead, so we likely can't limit the lookup.

We could limit follows to people who are bridged to Bluesky in turn though, if the Bluesky user isn't opted in explicitly. That would give nice parity and would mean the Bluesky user doesn't have to check their Bridgy Fed profile for invisible followers in case of problems. Everyone else would be left 'pending' until they opt in or cancel… but I'm bikeshedding here 😅)

---

On Bluesky, searches are completely invisible to Bridgy Fed. The account usually has to be actively 'pushed' into the ATProto network before it becomes visible there. We also can't see fediverse accounts or activity at all without at least one direct follow or an AP Relay connection from that instance. (Some can be discovered because it's mentioned in other activities or in collections on an actor, so it is often possible to crawl ActivityPub, but that's not enough to bridge anything in more-or-less real time.)

[^1]: Bridgy fed doesn't have to really do any automatic AT => AP processing at all unless there's an ActivityPub follower, since up to that point everything on ActivityPub is an incoming lookup that the bridge responds to directly.

[devilspeech]

I'm curious then, why exactly was Bluesky also made opt in from the start if all of the technical limitation is on fedi's side and there seemingly wasn't much if any personal objection from Bluesky's end? Was there even that much backlash specifically over the prospect of Bluesky users being bridged into fedi? Even then if an admin or user objects to that it's simple enough to just block the bridge domain and never have to see them, that's just normal inter-instance fedi moderation at the end of the day.

[Tamschi]

I don't know the exact reasons, but the bridge used to translate some content very incompletely from AT to AP (missing content warnings, sensitive media flags, quotes, attached links… Mentions still don't work properly when viewed from Mastodon, but that's because those are particularly contextual unlike nearly all other parts of the post and it took us ages to figure out the details).

There were definitely too many things that were invisibly broken at that point. Mentions are only visibly broken now though, they just behave as external links to Bluesky instead of loading the ActivityPub actor in Mastodon. Still not ideal, but at least clearly so.

[Tamschi]

Something that's also relevant here is #971, but that might be within reason for instance moderators to handle by silencing accounts that don't self-label (or the bsky.brid.gy domain entirely, more realistically) from the federated feed.

Even if #971 is implemented, it's not against the rules to post without self-labelling adult or graphic content on Bluesky, so I assume most admins would limit the instance at least a little bit to deal with posts that don't have a CW when they first arrive.

[shiribailem]

@shiribailem @devilspeech It's not just a minority. You can see this for example by comparing with Flipboard who got mass-defederated recently over bot activity.

Where are we getting this from? This like the "mass" defederation of Threads (a minority of admins throwing a fit, but at least they had some reason)?

Public opt-out bridging has been a part of federation from the beginning a part of the culture... the people complaining about the idea of it are the same kind of people who call the entire ActivityPub Fediverse "Mastodon".

[devilspeech]

Something that's also relevant here is #971, but that might be within reason for instance moderators to handle by silencing accounts that don't self-label (or the bsky.brid.gy domain entirely, more realistically) from the federated feed.

Even if #971 is implemented, it's not against the rules to post without self-labelling adult or graphic content on Bluesky, so I assume most admins would limit the instance at least a little bit to deal with posts that don't have a CW when they first arrive.

Yeah I have encountered this before, although so far I've seen more people who have self-labeled than those who haven't. It's still to be seen if Bluesky will develop a culture of consistently self-labeling or not. It's also an option for admins to apply sensitive media flags to individual posts (if reported) or to entire accounts so all of the media they upload is flagged. This is how my instance handles it for now if anyone reports bridged Bluesky posts that don't have CWs.

This is something fedi already has to deal with regardless of whether the bridge is opt in or opt out though. Silencing is a reasonable choice for any remote instance with incompatible rules, it's even fairly common to silence really large instances like mastodon.social just so they don't drown out the rest of the network if that seems like another issue or fear with Bluesky.

[devilspeech]

Public opt-out bridging has been a part of federation from the beginning a part of the culture... the people complaining about the idea of it are the same kind of people who call the entire ActivityPub Fediverse "Mastodon".

When the initial backlash was happening I admittedly didn't know that it would be necessary for the bridge to essentially follow/copy fediverse accounts en masse for opt out to function, since Bluesky can't see anything on AP otherwise. I'm wondering now if most of the people who were protesting back then were aware of this either, or if there was some miscommunication that happened along the way. Either way the dogpiling was still entirely uncalled for and reflected very poorly on the fediverse as a whole, even if it was only a small number of people doing the worst of it. Fedi culture is not a monolith but the loudest most unruly voices always end up being the ones who leave the biggest impression.

If the bridge from AP -> AT functioned exactly the same way as AT -> AP then I would also want it to be opt out, because then it's ultimately up to the users (or because it's fedi, the instance admins) to decide who gets bridged on an individual basis simply by following each other, or to decide they don't want to be followed and to block each other. That's just a public social platform for you, and also how users connect across different instances on the fediverse by default. I can however understand being hesitant with the way Bridgy has to handle AP -> AT, since even if the users didn't care it would presumably be a tall ask for Bridgy to essentially duplicate the entire fediverse to make opt out work smoothly.

Hopefully I'm understanding all of this correctly anyway, if not feel free to correct me.

[Tamschi]

I think that was part of the concern, but the larger issue was in terms of culture and that it would make "all posts" (I think that was a miscommunication) public and searchable. Fortunately the general vibe on Bluesky turned out far kinder than e.g. I expected overall, but that really wasn't that clear at the time.

[pcottle]

The bridge is like any other instance, no data is sent unless users choose to follow each other, and if you don't want to federate you can block the domain at the single click of button.

I agree with this -- and I'm hoping we can land some kind of instance opt-in (#1305) by the time Threads has more bidirectional Federation support (which is sooner than you might think). I can offer our decision in writing if that helps :P If anything, this would be like "treat us like any other instance, rather than a divergence from how activitypub normally works"

From the Threads side, we are in a federate by default (blocklist mode). The bridge is just any other instance, and I think our users would be super excited to be able to converse with (and see content from) Bluesky.

I actually think opt-in to start was the right choice from @snarfed, especially given the vastly different cultures between the two main platforms at the time and the heated debate that ensued. But now that the dust has settled from the concept of bridges, I think each community can decide what they want.

For Threads, more reach and more cross-instance relationship building is great! I imagine bluesky would feel the same way. We have pretty robust integrity controls so we're not worried as much about a big influx of users (and we are at 275M monthly users anyways).