The Bluesky Bridge

I believe that we should be able to interact with people who choose to use BlueSky or Threads, and I'm for limiting.

I understand that some of us don't want that, and that's fair; you have to have an option to block the domains. I hope this is enough to keep your data “private” from them.

But by pursuing privacy for yourself, you shouldn't limit options for the rest of us.

@Sieva I feel like the thought process in this comment makes sense, but also that it's somewhat backwards. I want people who want to communicate with BlueSky and Threads to do so, but the burden shouldn't be on me to explicitly opt myself out of that.

"You can just block the domains" requires me, personally, to keep track of all the corporate domains and bridges I don't want to interact with, which is an impossible task. The same doesn't go for the people who want to interact with them though, because the thought process isn't "I want to interact with every single domain in existance", it's "I specifically want to communicate with my friends in X corporate domain", and opting into that is already part of one's thought process.

@Sky Leite thanks for putting this into such nice words. Me not having English as a first language struggled.

Re the “impossible task”: EU GDPR also favors opt-in over -out for exactly this reason.

I am also in favor of allowing interaction with Bluesky and Threads. Much of my academic network already jumped from twitter to mastodon and then Bluesky. I’m happier here in the fediverse but respect the many colleagues who really don’t like it. I want to reach and read more people, not fewer.

I really appreciate you taking the action you did -- immediately limiting and then discussing here seems absolutely like the right initial step.

I'm also for limiting at the server level.

I too and am in favor of interacting with BlueSky. I strongly disagree with the mischaracterization of snarfed.org. I know Ryan, he's a full-on open source, federated person, very active in the indieweb space. He's a great guy and maligning his character is not a good look for our community. You can disagree with him of course, but to imply he's "giving the game away" with that quote is not only misunderstanding the quote (which is about the definition of federation) but to imply they are disreputable. We are better than this. I'm NOT saying you have to agree! I'm just saying let's disagree with a bit more humanity.

@Scott Jenson with respect, I disagree. He absolutely admits that consent isn't worth his time and that his product being successful is more important. Being an open source dev is great, much better than if he were building this for Google or somewhere, but it doesn't mean his motivations or desires are good and the blog post is really despicable in my opinion. I'm sure he's a nice guy whom it would be fun to hang out with, and maybe he's done a ton of other great software that helps people, but that doesn't make this at best a thoughtless and arrogant exercise of power and at worst a blatant violation of peoples rights.

@Sam Whited As I said before, my focus here is how we as a community should ethically communicate. You are making an unethical argument by manufacturing quotes he never said ( "That isn't worth my time") Even your description of his blog as "really despicable" add nothing to the real issue. Your invective is palpable here. Let's keep our pitchforks in the shed, shall we? Where are we Twitter?

@Scott Jenson I did not manufacture a quote or imply that that was a quote, but I do believe it's a fair and accurate reading of the post I linked. He violated all of our consent and has made it clear that he doesn't care or think it's a problem.

I'll refrain from commenting further in this manner and apologize if my language comes off as strong. I am not disparaging him to his face, name calling, or any of the other behavior that as a mod we try to avoid, but I do believe what he said in the blog post is absolutely not okay. Re-reading I think my statements still pass the three gates we often use for moderation purposes, but am open to being corrected if not.

TBF, I do owe him at least a partial apology. Every comment I'd read from him indicated that he wasn't taking peoples concerns seriously, but he does appear to be exploring other options as of a post he put out today. If he's decided to actively engage and find another way I think that's pretty great and I'm glad he's come around: https://snarfed.org/2024-02-13_52223

@Sam Whited I also know Ryan from previous interactions having to do with bridges and I can only say that he comes across as an ethical and well-intentioned person.

Also, full disclosure, I agree with him in that opt-out is better than opt-in in this case. We need to consider not only the direct effect on individuals who are anti-connectivity with other networks by default, but the indirect effects on the goals we are trying to accomplish: to give people in corporate platforms a window (and a way out) into the Fediverse, to reclaim the internet from unethical corporations in general and to fight back against walled gardens in particular.

@flancian In my experience, when a small organization tries to create a bridge to a larger, problematic organization, in hopes that it will help participants in the larger to escape to the smaller, it usually ends with the smaller organization absorbed into the larger.

Thank you, I agree limiting out of the gate is a good idea.

It's frustrating to me that this kind of thing isn't an immediate block, to be honest. I legitimately understand the points about wanting to communicate with people on those platforms, and I think they're valid, but to me the entire point of not having an account in those services is that the companies behind them can't (reasonably) use my words for whatever garbage they're producing this month. I don't even know how to emphasize how much I don't want that, so I guess this is all I have to say.

I agree that limiting the bridge, pending discussion, was the appropriate response. I don't like the fact that this bridge is opt-out, and I agree with what others have said on the Fediverse, that we use it to avoid the all-devouring corporate networks, so simply bridging them is unwelcome.

Thank you for taking this action quickly. My choice to join the fediverse hinged on the spirit behind "opt-in", not "opt-out". There are so many detrimental effects of using opt-out as the default, and very few truly detrimental effects of opt-in.

I’ve been going back and forth about a “well actually that’s not how it works” post but I defer to this one instead:

@jeremiah@tldr.nettime.org @snarfed.org@fed.brid.gy @sarae@ecoevo.social The entire fediverse is opt-out structure by default.

If you want opt-in I recommend moving to or setting up a whitelist instance (an instance configured to only federate with instances added to the whitelist, meaning all instances are opt-in by your admin).

https://foggyminds.com/display/c6ef095f-2165-cbe1-cace-beb789728853

I’m not saying “go find another instance” (which includes myself FWIW) but trying to make it work for both sides seems a bit futile to me.

@Henry (cryptix) thank you for this. I don't fully understand why people think this is significantly different from an instance running some new Fediverse software joining the Fediverse; I don't think we should block new instances running new ActivityPub-speaking software by default, no matter how large (although I do know that some people wanted to suspend Threads.net).

Seems like "block until opt-in is clearly implemented, then limit" is a good path?

Like any bridge, limit is the best call - giving interaction to other platforms, especially those where people migrate to is a better compromise than having to be there.

Point of note though, blocking brid.gy as a whole is not a great idea, there are other services that live on that domain like fed.brid.gy - if we're going for a block or limit bsky.brid.gy is the hostname to block without taking a hit of other Indieweb services

Thank you for preemptively limiting that domain while we discuss a policy going forward, @Sam Whited. I felt that that was the best course of action, too, yesterday, when I first read the announcement from the developer behind the bridge. I sympathize with your aversion to his post, as well, and know that you and I are not the only ones on the Social.Coop instance alone who were disturbed by what came off as massive flippancy towards others' concerns. I understand from reading upthread that he has a new post in which he'll be listening to others' concerns, and I really have to wonder if it would not have come so quickly were he to not catch fire for the one yesterday.

Edit: Oh, I see the opening lines from his new post:

Quite a day yesterday, and today so far. I’m obviously taking a beating from everyone who thinks the Bluesky bridge should be opt in. OK.

Good! I hope that for him, it was a learning experience.

It seems we have a diverse community here, with some different kinds of concerns about the impact of opening up access to a larger conversation with some very big corporate players.

I joined social.coop because this seems like a healthy sustainable community with principles I support that was less closed than the domain I left (which limited or blocked lots of larger instances, sometimes quite arbitrarily - which I’m really happy to see is not how things work here). I love that we talk to each other, decide things together and financially support this instance and its maintenance. I was under no illusion that all friends and academic colleagues would ditch the other big alternatives (T and FB) but I was hopeful that the unique federal structure of the fediverse would allow, eventually, a system where we could shape our own spaces while reaching out to other systems that want to converse with us. I think it would be a real shame if we closed down access to the voices of the much larger majority of fellow humans who we might want to hear and give the opportunity to hear us. When I saw a wave of academics move from mastodon to Bluesky and their (to my mind misplaced) enthusiasm of what they found on the other side (including their faith that some day soon they could renew conversations with Mastodon friends), I stayed put because the prospect of this future bridging would allow that broader conversation across broad networks.

I hope we can reach a compromise while mitigating some of the concerns. I’m not sure how blocking will prevent wholesale data grabs by a determined party. I regularly see bots scrape my domains without any regard for robots.txt and wonder how robust server defenses on the mastodon platform are to prevent some kind of mechanical scrape even without overt connections between platforms.

I look forward to us taking a vote on this. There seem to be strong opinions on each side. We have different needs and came here with different visions of the ideal fediverse so this is understandable. Unfortunately, if we take a road to blocking larger social networks (which will never meet our high standards of moderation, I suspect) connecting with us, I suspect I’ll have to move on with sadness for the same reason that I initially moved here from my last instance. With deep respect, Konrad

Dear all, thanks for your thoughful comments, and specially to @Sam Whited , for your prompt and clear action and explanation.

AFAIK, if we assume the default is to opt-out we are de facto stomping over other people's rights by default (sorry if it sounds too harsh, English is not my native language) and leaving over their shoulders the actions to defend themselves. Notwithstanding each one's opinion, its is almost impossible to delist each and every domain that we might think is rogue with our rights, but very much and specially so with these services and people that had many years of concrete history of not caring about anyone's right except theirs own to accrue more money at other's people life's expense.

I'm ok if anyone want's to exchange with Facebook or Bluesky, it is their choice, but by default I do not. So, in my opinion the option for those very much proven bad faith actors is that we should behave with those services as an opt-in option.

Thanks a lot in advance for your comments/views. :)

Best...

"If bridges were opt-in, and I could only follow 4% of people on other networks, they would be drastically less useful." in other words, he doesn't care about your consent.

I think this is misleading. It's not that he doesn't care about consent. He is saying he doesn't think he needs consent when gathering data published openly on the web and interacting with APIs that are made public for that reason. Consent for federation is implicit in having an open API in the first place.

We don't have to be part of the open web. Some Mastodon instances have opted out entirely, but we are not among them.

@benjaminmakohill I've seen a few people express the idea that there's more to a social contract than just the formal details. This is one of the clearer explanations I've seen of how it's relevant here.
https://mastodon.me.uk/@CatherineFlick/111929330291726562

@Brian Vaughan It is a very thoughtful post. The author makes it clear there isn't a consensus about what the social contract should include for the reuse of data on the Fediverse. This is obviously true based on the fact that we're arguing about it here! I'm making a claim that I think the author from Bluesky's implicit argument that an open/public API for federation implies consent for doing federation is reasonable.

I think this interpretation is in line with the way the Internet has worked over the last two decades and is essential for important things built on the open web, blogging and RSS, the Internet Archive, search engines, and more.

@Brian Vaughan

Thanks for posting the link, Brian.

Unrelatedly, I'm not sure if this is a Loomio issue or what, but I had to edit the URL in order to not get a 404 error. As an experiment, I'm pasting below the version of the Catherine Flick link that does work for me:

https://mastodon.me.uk/@CatherineFlick/111929330291726562

(curious if that will continue to work after I post my comment)

@Benjamin Mako Hill thanks for relaying that; I agree with him there. The question here to me is: does Social.coop want to be part of the Internet as well as part of the Fediverse? If the answer is yes, then I think our current settings (profiles and posts visible; no authorized fetch; 'opt-out' federation) make sense. If the answer is no: I would personally probably move to another instance. But I respect the opinion and choice of people who might want to run an instance with more 'conservative'/'risk averse' defaults.

I'm not going to go so far as to say that I'm against any federation to a bluesky bridge no matter what. But I am, at least right now, against it until we have some sufficient understanding of what this bridge will actually look like in practice (maybe we do and I'm just missing it, so please share if you've got it).

I'd prefer a look before we leap approach on this one. Will bluesky appear all as one instance when it gets bridged in? Will we have any capacity to defederate parts of bluesky or will it all be one big instance? Would we effectively be federating onto a single very large instance which includes a lot of bad actors and a management model we don't trust? Do we have the resources in our instance to respond to that (moderation capacity, etc.)?

I don't think this is really in the same bucket as implicit opt-in for some random new instance of 50 people, in a practical sense.

I'm not sure that the parallel between BlueSky and Thread is 100% appropriate here, given that in the case of Threads the data disappears into a fully private silo, whereas on BlueSky all the data is accessible as a big public stream. Depending on your threat model this can make BlueSky both better and worse than Threads.

In this particular case I think the decision to limit the BlueSky bridge is sound, but in the future I don't think we can automatically apply decisions made for one platform to the other.

Hi all, Eduardo from the TWG and CWG here -- voicing my personal opinions and not those of the workgroups.

First of all, thank you Sam for starting this thread and taking early action in the interest of the community.

Second of all, I am personally not in favor of suspending or even limiting this bridge. In general I am pro-bridges and prefer a larger size and higher connectivity for the Fediverse by default, and I don't see a reason here to change my default position. Some points to support this position follow.

From a technical point of view it's unclear to me in which way specifically the BlueSky bridge is distinct from any other new ActivityPub implementation. We don't federate only with Mastodon instances (thankfully); new servers are being written all the time, and everybody in Social.coop is able to interact with them right off the bat. The fact that this particular software is a bridge seems like an implementation detail to me, so I think it shouldn't be very relevant when deciding on which federation policy we want to follow. From now on I will assume that people are mostly objecting to the network behind the bridge (that is, the people) or to the group behind Bluesky (that is, the company), and not to the notion of bridging proper.

From a network-centric point of view I am unaware of the Bluesky community being problematic in any particular way, except maybe the fact that it's already relatively large by Fediverse instance standards. But I hope the Fediverse is not afraid of big instances as a whole, even if some of us prefer smaller instances; or else, should we block or limit mastodon.social?

From a company-centric point of view I understand the concerns of people who, paraphrasing, want to prevent corporations in particular from getting their data. But here again I don't understand why/how Bluesky is different here to any number of Mastodon instances run by for-profit corporations; those exist and IIUC we don't block them preemptively.

After I take the above, and I add the fact that people are able to opt-out from interactions over the bridge, I see no big issue here personally. Full disclosure: If I were in Ryan's place, I would probably pursue the same policy.

I will close by paraphrasing something I said in a reply above. I believe with this valuable discussion and the past one on Threads.net, Social.coop is inching forward towards a deeper and potentially instance-dividing question. I would phrase it as such: does Social.coop want to try to remain a full member of the open Internet and the Fediverse? If the answer is yes, then I think our current settings and policies (profiles and posts visible for scraping; no authorized fetch; open federation with an opt-out model) make sense. If the answer is no: I respect the opinion and choice of people who might want to run an instance with more 'conservative'/'risk averse' defaults, but I would personally probably move to another instance.

Thank you for reading, and I appreciate in advance your continued participation in this conversation.

I support keeping the moderation level at limit.

I would also prefer---if we end up having a formal proposal on this topic---if it could be framed as a generally applicable proposal, so that we don't need to relitigate this every time a corporate fediverse instance (or bridge to a corporate instance) pops up.

@Dynamic Hi!

I strongly support this proposal. We started something similar with Threads (PosiFedi, https://cryptpad.fr/pad/#/2/pad/edit/5xxQZvxvjfAP2eQTYenLuWOZ/) but it lost movement.

It could be really helpful for everyone to have a policy on agreed conditions to federate.

@Jonobie Ford Out of curiosity, do you find this substantially different from Threads? I know we voted (generally speaking, I don't know how you personally voted) to limit that since it effectively makes it opt-in, but I'd be curious if folks think this is different.

@Sam Whited Not really - I think both of them, for me, were a sort of "wait and see" response. But as time goes on, I lean more towards a more open and connected server, because I would like to connect with folks who are on those other platforms.

I am a little uncomfortable with how this was setup too, FWIW. The framing as a vote to unlimit feels wrong to me: there are three options here (suspend, limit, unlimit) but only two of them are included and "other" seems like a bit of a spoiler, as you said.

@Sam Whited Thank you for your feedback! Yes, ranked choice just wasn't a good idea here :) I have started a new vote using our governance template, please see below.

To add on to this there is a mechanism for users to completely opt-out, I agree an opt-in would have been better but the argument can be made that anybody can spin up a Mastodon instance and effectively require the same result https://fed.brid.gy/docs#opt-out