Switch Bluesky to opt out? #1471
Comments
|
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. |
|
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. |
|
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. |
|
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... |
|
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. |
|
I personally would recommend to post about this issue on bluesky and try to get as many opinions as possible |
|
@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.) Before bridging groups of accounts without individual opt-in though (in either direction), I think it's important to have #1406 first. |
|
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. |
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 . |
|
@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 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. Footnotes
|
|
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. |
|
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. |
|
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 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. |
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". |
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. |
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. |
|
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. |
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). |
|
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. |
|
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. |
|
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. |
|
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. |
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 haven't decided on a mechanism, but yes that's #1305. |
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) |
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. |
|
I think we pretty much have a unanimous decision now: bsky bridging should be opt out! |
It's only those, yes. (Discovery and indexing are the two major differences where someone can't opt out on Bluesky.) Misskey also has a profile attribute to hide users from guests iirc, but I think behaves like the matching option on Bluesky. |
Opt-in also gives everyone the freedom to decide for themselves. For consent to be meaningful, it needs to be a freely given, informed, affirmative act. Opt-out assumes consent without the person making an affirmative act or necessarily being informed. As a result, opt-out doesn't protect people who are potentially at risk. It's a fair point that Bluesky's current model is non-consensual data sharing, and leaving it up to people who are potentially at risk to protect themselves, so I can certainly see the argument that Bridgy Fed should have an opt-out model for Bluesky users. Still, the reaction to the Hugging Face incident implies that many users don't like Bluesky's non-consensual approach, enough that Bluesky's at least saying that they're considering implementing an (advisory) consent mechanism. So I can also see the argument for keeping it opt-in on the Bluesky side. |
|
I don't think you can reasonably argue that there isn't a fundamental difference between mass scraping and protocol bridging. Using Bluesky fundamentally requires granting consent for your data to travel between servers. |
|
Is there any update on this after the organization news? |
|
Organization news? |
Referring to this: https://snarfed.org/2024-11-01_53932 and afterwards we got https://www.anew.social/hello-social-web/ So I was just wondering |
|
@AtiusAmy sorry, no news yet. We'd love to work more on this eventually! |
|
This would be really nice in order to onboard new people to fedi, so they know that they can still talk to their friends on bsky without explaining to them to follow a bot |
|
Thanks for linking all related issues, it helps seeing how much of a recurrent theme it is! (My atypical Github user/ less tech-savvy view #1790). I quote from elsewhere what you said @snarfed "If a platform or network like the fediverse is opt in, and someone has explicitly chosen not to opt in, they'd generally expect that bridge not to deliver their content or profile or interactions anywhere." I'd just like to add the nuance of 'explicitly chosen not to opt in'. For a tech savvy person, 100%, they understand optin/optout. For the average user however, it is not as clear. I liked the suggestion @shiribailem made about echo accounts, or @ch0ccyra1n which both point to the fact that people don't know where accounts live and won't know an account is bridged, or for that matter, not care where this account lives. They show however through their behaviour interacting with it, that they expect to be able to do so and not have to worry about the name of the account or something as techie as 'what server does it live on'. They are further encouraged to think the bridge is nothing, as they are able to follow the account without any sort of warning when they do so. From a newbie's perspective, it makes zero sense to differentiate these actions, which basically all amount to 'interacting with an account'. So for comments, maybe a warning message before something gets posted, along the lines of: If the latter, they should have a confirmation DM with something like "Congrats! You are now bridged to the Fediverse! This means that... If you change your mind..." I am assuming here that consent:
|
|
yeah, not only for comments, for following also. |
Hi, I don't know much about bsky, but I don't see consent could be asked before the comment is posted. It's not like Bridgy Fed controls the bsky instance. |
|
The vast majority of people don't care where their data is stored. They just want a well-functioning app and want to see the messages of the people they are interested in, and some of them want to interact with them. For all these people, anything other than opt-out is simply a bad user experience because they are being restricted for no understandable reason. And of the minority who are concerned about which company's server the data is stored on, most of them didn't choose Bluesky or Mastodon for nothing, who both advertise that you not locked in with this company. For these people, anything other than an out-out contradicts the philosophy of these platforms. There is a minority of this minority who want their posts to be forwarded to some other servers, but not to other other servers. These people are vocal advocates of opt-in. |
To the contrary: in my poll last year, 71% preferred opt-in for a bridge to Bluesky. (And that was before the publicity about Bluesky datasets being posted on Hugging Face, or the ramp-up of anti-trans abuse on Bluesky.) And this is consistent with attitudes in generally. In 2023, polls in Washington state showed over 70% support for opt-in data protection. Consent is popular! It's extremely popular with women and trans and non-binary people, but a lot of cis guys think consent is a good thing too! |
Well, not exactly a scientific survey with a statistically random selection of all users. That's what I mean by "vocal advocates". I would be cautious about allowing far-reaching decisions of great consequence to be determined by a very small but vocal minority.
This is about something completely different. It's about personal and private data. Not data that you specifically make available to the public for distribution to other servers. You join a Mastodon server precisely for the purpose of having it forward your posts to other servers (or not), according to your server's policy. And even if you don't like the server's policy, but for whatever reason you still want to stay on the server, you can block other servers as much as you want. At least in case the server blocks too little for your liking. If it blocks too much, you have a problem. |
|
I'm sorry to interrupt, but isn't this about Bluesky opt out? First, and if I'm right, Bluesky posts are public anyway. So basically, the Fediverse just need a translation bridge to access them. In the same time, a Fediverse public post should also be readable through a similar bridge to the Bluesky network. Should we skip the restricted posts from the conversation for now? bridge-fed does not handle them anyway right? That being said, and in my opinion, Bluesky users never had the choice to restrict their posts visibility. They just posts things that anyone can read. In the contrary, Mastodon/Pleroma/etc users can restrict their posts visibility, and should not be surprised that their public posts can be read from another network. edit: btw I understand that both network technically work very differently, and that this isn't just about a basic message translation layer. |
The thread is supposed to be about Bluesky opt-out but people keep trying to relitigate the decision to have fediverse consent be opt in.
Yes, but consent matters, even for public posts. Look at how many people were upset when the Bluesky datasets wound up on Hugging Face. Or, more broadly, think about how many people are upset at AI companies scooping up data.
Quite a few Mastodon (etc) users said they don't want their posts winding up on Bluesky without their consent. At this point I don't think anybody's surprised when projects ignore consent (or with Bridgy Fed, propose ignoring consent -- @snarfed was one of the very few people who actually got feedback on their proposal). But even though they're not suprirsed, they get angry when this happens -- and frustrated since this battle keeps getting refought. With Bluesky, it's harder to know. I was surprised that there such a loud outcry about the Hugging Face datasets -- I had that that people there knew and were okay with the fact that Bluesky's CEO was encouraging this kind of behavior. So my feedback to earlier in this thread is to be careful about the assumption that most people on Bluesky want opt-in -- it might be true, but it's worth validating. From @praichor's post:
Sure, and neither is you claiming that it's only a minority who prefer opt-in. I've talked to hundreds of non-techies about this over the last few years in the fediverse and elsewhere, and I see the same thing consistently: women, trans, and non-binary people overwhelmingly prefer consent.
No, it's about different aspects of the same thing: consent.
No, very few people joiedn Mastodon servers with the expectation of their posts being forwarded to Bluesky. It's a different culture: Bluesky is an architecture optimized for surveillance capitalism. They don't ban anti-LGBTQIA2S+ bigots or fascists. People joining up on Bluesky know that (or should know that); that's the choice they're making. People signing up on Mastodon aren't choosing that. |
|
@jonpincus I'm wondering if the same people also don't want it to be possible to follow them and start receiving their posts automatically from e.g. mastodon.social or other biggest Mastodon/Fedi instances, which might have imperfect moderation too? If not, why not, is it because it's ActivityPub based? |
In general people on Mastodon see mastodon.social and other big servers as part of "Mastodon", the network they signed up for. But it's not just a matter of people following them from the other instance. Even if Ive chosen the option to approve followers and don't accept anybody from Bluesky, if it was opt-out my posts could potentiall be shared to Bluesky without my knowledge or consent if somebody who does have followers on Bluesky boosts them. |
Hm, no, I don't think so? In order for a boost to be bridged (in the form of someone's Bluesky-mirror doing a Bluesky-repost), that post must already have its Bluesky representation, boosting can't create it on demand. And the post will only have a Bluesky copy if at least one person is following that Mastodon account from Bluesky - because Bridgy doesn't "fetch" posts through some fetch API, it just uses ActivityPub following, which works in such way that you only start being sent posts from the author when you follow them. So the whole thing was just about whether:
|
|
Hmm, you're right that I was making an assumpoint -- that's how boosting works in other situations. With the current version, your posts flow to Bluesky if you've opted in (whether or not you have any followers). If it had gone the opt-out route, posts would presumably still flow if you've got at least one follower there, but there would have been an implementation choice about whether to bridge a boost (by an account that had at least one Blueksy follower) of a post by an account that hadn't opted out of bridging. |
This is a widely spread misunderstanding of how the Fediverse works. In the Fediverse there is no "joining up on Bluesky" versus "signing up on Mastodon". In the Fediverse (regardless of the technical details of ActivityPub versus ATProto most people don't care about) there are countless different servers and operators with their own, sometimes very different moderation rules, very different cultures. You are signing up to one of very many servers and choose its specific moderation rules and culture. A lot of education is still needed here. However, a lack of knowledge should not be a reason to unnecessarily restrict the freedom of social networks technically. Instead, every user should have the freedom to decide what should be forwarded, how and where. Someone who does not want their posts to be forwarded to Bluesky can simply choose a server that they consider secure and which does not do this. It's simple for admins to configure their server: https://fedi.tips/how-to-defederate-fediblock-a-server-on-mastodon/ You can also use a whitelist approach: https://docs.joinmastodon.org/admin/config/#limited_federation_mode Or a user can simply block the server directly. Mastadon makes this easily possible: https://docs.joinmastodon.org/user/moderating/#block-domain There is no need to patronize the vast majority of users with unnecessary technical restrictions. |
|
I agree with both sides of this discussion -- that the core of the Fediverse is about interoperability and content portability between servers, and that a lot of Mastodon users might not want their content to end up on Bluesky (purely due to cultural and emotional reasons). I'm wondering if theres a possible compromise in using server size as a guidance towards whether the experience is opt-in vs opt-out? If bluesky has 30 million users, Threads has 320 million MAU, and Mastodon.social has 2.5M users, signing up on those servers is essentially signing up for the public internet -- there are just so many people that the incremental risk of bridging your content is fairly minimal. But if you sign up for the "LGBTQIA+ Tech Mastodon" instance, you don't expect the kind of visibility on your posts to increase beyond the few thousand people on your local server. Even if just the top ~5 servers on FediDB were allowlisted: That would greatly expand functionality without requiring the longtail of communities to change anything or do anything proactively. |
|
Rather than having a limit on server size (which I agree makes sense), it may be better to make a toggle for entire instances to be opt-in, which could be done by Mastodon server admins. I thought there was a discussion about that elsewhere already, but I can't find it now. Regardless - I do think the Mastodon side of things is/should be a completely separate issue. This is specifically making Bluesky itself opt-out instead of opt-in, which IMO would be healthy for the fediverse writ large (as it would make a migration to Mastodon easier when the majority of Bluesky accounts already are bridged). IMO, all Bluesky accounts should be auto-bridged unless they have the toggle to only allow showing their profile to logged-in users. (I thought we already arrived at this conclusion at some point?) |
Yes! Agreed, we're actively working on this, it's #1305. |
The administrator of this instance can simply block the bridge. |
and others
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.
The text was updated successfully, but these errors were encountered: