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 the Discourage apps from showing my account to logged-out users setting 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).

[snarfed]

Thanks for the vote of confidence @pcottle! I'm definitely partial to that perspective on AP federation and bridges too. And we're excited for Threads integration! Following up on instance level opt in for Threads etc on #1305...

[FurblandChannel]

I honestly am in support of making it opt-out, I feel like it’s very hard to get people to bridge otherwise. (I know from experience!) Though maybe only create the profiles upon request from a fediverse user, we don’t want random crawls overloading servers.

[FurblandChannel]

Actually, you might also want to create profiles upon interaction with a bridged user before then bridging the interaction. Point being, don't just go around making a profile for every account on a server unprompted.

[lupomancer]

Opt-in would be the dream. The bridge is in such a great position now with the ability to set your handle on the BSKY end.

If the bridge was opt-in, I could wind down my BSKY accounts completely.

I will echo what others said in saying you were dogpiled by a very vocal minority from Fedi. I agree they have good reasons, but I also feel like people who have those worries are also capable of opting out. Anyone else will just benefit from an interconnected network.

Scalability is a huge question though, and I could see that getting out of hand quickly. I think only creating an account on user poll (searching for an account) is a good idea. Mastodon's user base is small, and the users of the bridge are even less. No need to boil the ocean for a small subset of people who will only follow a small subset of BSKY accounts.

As for BSKY's feelings on the matter; I think most users don't even know about the bridge, but would be okay with it if they were just opted in. For most people, any friction at all is too much. Even just following a weird account that they're being asked to follow by a random person.

[db0]

I agree with opt-out on bsky. I created a test account for myself and didn't get the DM from mastodon because I didn't realize it blocks PMs by default.

Btw, what does one do if the PM they got from the bot is lost because their chat settings hid it? I can't see the chat message in bsky anymore and no new one is being sent.

About opt-out from mastodon users. I know there was a massive blowback the first time, but what if an instance admin could set their whole instance as opt-out through a DNS text record? This way instance admins who are not against it can set it that way.

[Tamschi]

Btw, what does one do if the PM they got from the bot is lost because their chat settings hid it? I can't see the chat message in bsky anymore and no new one is being sent.

I don't know if we can distinguish between users who were sent the DM and those who didn't receive it due to their Chat settings. That should arrive with #1326, after which you could retry after seeing the error message.

I'm not sure what to do about earlier cases. If we just re-enable it, that would risk sending the request twice to some users. We should probably expunge seen accounts after a (long) timeout though, at which point requesting would become possible again.

About opt-out from mastodon users. I know there was a massive blowback the first time, but what if an instance admin could set their whole instance as opt-out through a DNS text record? This way instance admins who are not against it can set it that way.

We haven't decided on a mechanism, but yes that's #1305.

[therealNAAN]

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.

This, so much! It's very telling that (in my personal experience!) it's been easier to explain to people outside the US about how the bridge works--whereas with Americans, I don't know why, it has been WORSE than pulling teeth! I think I can count on one hand the amount of people in the latter who've understood what I meant. Heck, I've gotten people telling me I'm wrong because Sky Follower Bridge already worked for them. And this is after I explicitly say BridgyFed by name! I've accidentally chewed someone's head off after the nth time this has happened. (I apologized later, don't worry, readers at home.)

That said, I would like to mention something that a dear friend of mine said on Bluesky when helping to promote the bridge: anyone on Fedi who is interested in the bridge and has been trying their damnedest to inform Bsky users are the nice people, because anyone who gave everyone else grief over it has already blocked anything BridgyFed on their end. Take that as you will, but I wholeheartedly support making Bluesky opt-out or whatever will make it easier for their accounts to bridge into the Fediverse. Because not going to lie, methinks the users over there are content with never having to do the work we've had to do to keep in touch with our communities and friends who've moved over there...

(Sorry if this ended up being more of a rant than actual helpfulness ^^; My answer is just yes, make it opt-out lol)

[michael-patchwork]

Thanks for the vote of confidence @pcottle! I'm definitely partial to that perspective on AP federation and bridges too. And we're excited for Threads integration! Following up on instance level opt in for Threads etc on #1305...

Great to see this conversation! @snarfed this is the right time to make the bridge opt out on Bsky - yes. In the early days we could go around asking people to bridge, but with so many joining, including many people Fedi users would like to follow, Bsky opt out is the way to go. Also you've now made everything more stable. All subject to getting the governance sorted as you've flagged.

On the Fedi side, instance opt in would be great. So that's a yes to both.

[FurblandChannel]

I think we pretty much have a unanimous decision now: bsky bridging should be opt out!

[pcottle]

@snarfed thoughts on making a post on bluesky to solicit opinions? Maybe posting from the bridgy fed account + soliciting reposts?

I just want to know what the wider community thinks (even if there is some selection bias)

[mackuba]

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 (…)

Yeah, I think you've more or less described my experience with trying to ask people on Mastodon to enable the bridge too ;)

[snarfed]

@snarfed thoughts on making a post on bluesky to solicit opinions? Maybe posting from the bridgy fed account + soliciting reposts?

Yes! Definitely the right idea. I'll admit that I'm a little gun-shy, but whatever, still worthwhile. Will do!

[mackuba]

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.

@snarfed, just to clarify - as I understand, the initial pre-GitHub-thread-drama plan was that no Mastodon account would have a bridged copy created on AT side automatically just when the bridge is launched, but that you'd DM the bot on Bluesky like right now, "hey bot I want to follow snarfed@mastodon.social", and then that account would be bridged at that point for me, without having to first ask the Mastodon user to enable it? Is that right?

[Tamschi]

There's one safety aspect I'd like to see with out-out: Allow only bridged followers unless the Bluesky account opts in explicitly.

If we don't do that, then Bluesky users won't have fully native control over their followers, which is a bit of a problem (#1406) since we also can't reliably notify them of off-network followers either.

(That doesn't yet take list blocking into account though. Translating that properly into individual blocks would be very heavy though, to the point where I'm not sure it makes much sense. Could Bridgy Fed ask Bluesky's AppView about the block relationship on the fly and Reject the Follow on the AP side at least? I don't think we can easily block there since we aren't notified of list block changes all too easily.)

[snarfed]

@snarfed, just to clarify - as I understand, the initial pre-GitHub-thread-drama plan was that no Mastodon account would have a bridged copy created on AT side automatically just when the bridge is launched, but that you'd DM the bot on Bluesky like right now, "hey bot I want to follow snarfed@mastodon.social", and then that account would be bridged at that point for me, without having to first ask the Mastodon user to enable it? Is that right?

Right!

[rossabaker]

Blocking individuals on public feeds may seem futile, easily defeated by alts and logged-out views. But beyond the minor nuisance to the blocked, it's an explicit withdrawal of consent by the blocker. Bridging these expressions of consent is just as important as bridging our expressions of creativity. As a Fedi-to-Bsky user, I would gain a lot from this proposal. But until we can bridge both types of expression, such as with #1406, I think the opt-in remains the right approach.

[EmilJacobs]

Opt-out as the default would make the bridge so much more useful. I currently have 500 followers on my bridged account at Bluesky, but only a small fraction, about 25, are visible to me on Mastodon. While the consent people raise a valid point, most people, like 90%, simply don't care either way. All they care about, and frankly all I care about, is using the platform in as frictionless way as possible. An extra click to follow the bridge seems trivial, but like some else already said, it's akin to pulling out teeth. I give this idea a yay!

[praichor]

Unfortunately, opt-in ultimately makes the bridge unusable in practice. As a Mastodon user, I cannot persuade everyone I want to follow on Bluesky to turn on the bridge. In particular, it is impossible to get the attention of celebitry users.

The service is only really useful with opt-out.

And how cool is this bridge!

I also cannot understand the arguments against opt-out: On both sides of the bridge, the basic idea of ​​federation is that the data can be accessed by any other server in the federation, not just current but also future ones. In other words, the data is completely public anyway. You agree to this as soon as you register with a federating social network.

Theoretical question: Would you disapprove, would there a reason against it or would there be anything stopping me from simply hosting a modified opt-out branch of bridgy-fed with a new domain myself? Whoever on Mastodon has something against it can then simply block the domain I use.

(Repost of https://github.com/snarfed/bridgy-fed/issues/1305#issuecomment-2482737419)

[nileane]

Yeah, I fully agree that making the bridge opt-out for Bluesky users is the way to go to make it useful to wider range of users on both sides of the bridge.

[pcottle]

the basic idea of ​​federation is that the data can be accessed by any other server in the federation, not just current but also future ones.

I agree that the openness of Federation doesn't match the opt-in behavior of the bridge. I just think there was a huge culture divide between bluesky and mastodon, which is why opt-in was the right choice

Would you disapprove, would there a reason against it or would there be anything stopping me from simply hosting a modified opt-out branch of bridgy-fed with a new domain myself?

The confusing thing here is that I think every bluesky user and every activitypub user would be duplicated once per bridge, since you'd be on another domain. Not entirely sure of that, but I think having just one bridge is better than having multiple (when they will all be piping the same content)

[praichor]

the basic idea of ​​federation is that the data can be accessed by any other server in the federation, not just current but also future ones.

I agree that the openness of Federation doesn't match the opt-in behavior of the bridge. I just think there was a huge culture divide between bluesky and mastodon, which is why opt-in was the right choice

I haven't followed it closely, but wasn't the resistance to opt-out exclusively on the AP side? In other words, no obstacle to Bluesky opt-out?

Would you disapprove, would there a reason against it or would there be anything stopping me from simply hosting a modified opt-out branch of bridgy-fed with a new domain myself?

The confusing thing here is that I think every bluesky user and every activitypub user would be duplicated once per bridge, since you'd be on another domain. Not entirely sure of that, but I think having just one bridge is better than having multiple (when they will all be piping the same content)

Without having thought it through in detail, but wouldn't duplicate bridge accounts only exist if people explicitly used both bridges?

[pcottle]

Yeah the duplicates would only exist for those who opted-in to the opt-in bridge. But I still think it would be great to preserve all the follow edges and media objects that the existing bridge has ported over :)

but wasn't the resistance to opt-out exclusively on the AP side?

I believe so! Ryan knows best though

[snarfed]

You all are definitely right about multiple bridges causing duplicate accounts. We have this problem now! https://fietkau.software/pinhole , https://rss-parrot.net/ , etc. We've talked about a lot of possible technical approaches in #800, but afaik no other bridge developers have seriously taken me up on it and jumped into design or development there yet.

[snarfed]

Also, another angle on the Bluesky opt out question: there's a lot of interest in instance admins being able to turn the bridge on automatically, ie make it opt out, for everyone on their instance: #1305. Flipboard, Threads, and a number of Mastodon instances are interested in doing this.

As discussed here earlier, in many ways, the question of whether to make Bluesky opt out feels similar. ATProto is a decentralized network, the Bluesky team just owns and administers the biggest instance, and they all explicitly want tools like Bridgy Fed to be opt out. I'd of course make it as easy as possible for users to opt out, but for Bluesky users who disagree with that stance by their admins, that might be enough motivation for them to move to a different PDS (ie instance), just like users in the fediverse can take admin approaches into account when choosing their instance.

[tesaguri]

While I agree that it'd be nice to make bridges from Bluesky opt out, I feel like it needs more precise justification than "making something publicly accessible entails permission for bridge." There are plenty of nuances outside of the dichotomy of "public vs. private", like Mastodon's Quiet Public and discoverable, FEP-5feb/FEP-268d search consents and RFC 9309 (Robots Exclusion Protocol), most of which don't have direct counterpart concept on Bluesky and thus make ActivityPub-to-AT-Protocol bridges highly debatable.

So, why are bridges from Bluesky considered okay? Here's how I understand the rationale: In the world of AT Protocol, or the Atmosphere, the users' posts are distributed by servers (Personal Data Servers), typically in response to crawling requests by "relays" for aggregation by arbitrary "AppViews" subscribing to the relays (which include Bluesky). This is in contrast to ActivityPub's architecture where servers have a moderate level of control over how their users' activities are delivered.

In Atmosphere, the common practice is that the posts' schemata ("lexicons") are documenting how they are expected to be aggregated and presented, and the Bluesky lexicon doesn't have much "nuances" like in the Fediverse, with the exception of the logged-in visibility (!no-unauthenticated label, resolved in #828) and reply controls (tracked in #1098, blocked on standardization efforts on the Fediverse's side). So, keeping in mind those limited set of signaling mechanisms, BF is not very different from other AppViews in that it just aggregates and presents the posts according to the schema.

[michael-patchwork]

Also, another angle on the Bluesky opt out question: there's a lot of interest in instance admins being able to turn the bridge on automatically, ie make it opt out, for everyone on their instance: #1305. Flipboard, Threads, and a number of Mastodon instances are interested in doing this.

As discussed here earlier, in many ways, the question of whether to make Bluesky opt out feels similar. ATProto is a decentralized network, the Bluesky team just owns and administers the biggest instance, and they all explicitly want tools like Bridgy Fed to be opt out. I'd of course make it as easy as possible for users to opt out, but for Bluesky users who disagree with that stance by their admins, that might be enough motivation for them to move to a different PDS (ie instance), just like users in the fediverse can take admin approaches into account when choosing their instance.

Great point!

[pcottle]

Yeah great points! I wonder if we can land on these two decisions:

• ActivityPub instances, given the dynamics of the protocol, should have instance-level opt-in controls (#1305). Threads would sign up in a heartbeat, but it would avoid a lot of thrash there.
• ATProto is a decentralized protocol and this bridge similar to any other app running on ATProto. Obviously would be worth giving the team at Bluesky a heads up, but I find Ryan's arguments above solid that they want experimentation and developers to build and the ecosystem to be open.

[db0]

the Bluesky team just owns and administers the biggest instance, and they all explicitly want tools like Bridgy Fed to be opt out.

I was not aware of that. So they've explicitly requested this?

[praichor]

Yeah great points! I wonder if we can land on these two decisions:

* ActivityPub instances, given the dynamics of the protocol, should have instance-level opt-in controls ([Instance Opt-in #1305](https://github.com/snarfed/bridgy-fed/issues/1305)). Threads would sign up in a heartbeat, but it would avoid a lot of thrash there.

* ATProto is a decentralized protocol and this bridge similar to any other app running on ATProto. Obviously would be worth giving the team at Bluesky a heads up, but I find Ryan's arguments above solid that they _want_ experimentation and developers to build and the ecosystem to be open.

Sounds great:

Even the more cautious Mastodon server admins shouldn't have a problem with this, as opt-in applies to them.

But someone who wants to use one account to operate uniformly on Mastodon, Threads and Bluesky and doesn't have the option to do so today can do so in the future with a Mastodon or Threads account.

(Ignoring the fact that federating in threads is unfortunately opt-in, but that's another topic.)

[Tamschi]

the Bluesky team just owns and administers the biggest instance, and they all explicitly want tools like Bridgy Fed to be opt out.

I was not aware of that. So they've explicitly requested this?

It was more of a general statement regarding compatible services/bridges I believe (though within a conversation about Bridgy Fed), but I don't have it on hand and could misremember.

In any case, I think the main blocker for Bluesky-side opt-out right now isn't whether this would be acceptable socially (I suspect so) or map well at a protocol level (Interaction controls wouldn't map well yet, though Bluesky does filter out almost all effects of disallowed interactions. Bridgy Fed could also choose to specifically not bridge posts that have interaction controls on them.), but that Bridgy Fed as a project isn't necessarily ready to make these decisions: Possible futures for Bridgy Fed

(Edit: Hm, though judging by the recent now label it could be under consideration 🤔 I'm not entirely up-to-date with this, so despite my "Collaborator" badge up there ↗, please consider this as written by an outside observer.)

[snarfed]

@Tamschi is right on all counts! And sorry for the confusion, I think I added the now label to this issue just to remind me to make the public post to request feedback that @pcottle mentioned in https://github.com/snarfed/bridgy-fed/issues/1471#issuecomment-2478771409, not to mean that I'm actively planning for or working on making Bluesky opt out yet. That's still blocked on real organization structure, maybe funding, etc.

[snarfed]

@praichor, re:

Theoretical question: Would you disapprove, would there a reason against it or would there be anything stopping me from simply hosting a modified opt-out branch of bridgy-fed with a new domain myself? Whoever on Mastodon has something against it can then simply block the domain I use.

Hah, yes! The agony and ecstasy of open source. It's public domain licensed, so there's definitely nothing stopping you. I have no illusion that I can control or (necessarily) influence what other people do with my open source code.

I'd love to see other bridges! If we started seeing a lot more, I think we'd need to seriously tackle #800, which is possible.

Otherwise, Bridgy Fed itself isn't designed to be easily self-hosted, it's somewhat tied to Google Cloud, but it's very doable to run another instance of it there. It's also not designed to be easily "white labeled," yet, so if anyone does run a new instance, I'd strongly encourage them to rename it and otherwise update the front page and docs to make it clear that it's a different service, run by someone else.

Regardless, happy to help if you want to try!