The Bluesky Bridge

@Dynamic thank you for your feedback!

To clarify, I believe there is no standing policy decision for limiting the bridge and its developer (we also limited their personal domain). That was a preemptive measure by a moderator, but there was no vote passed to limit as far as I can tell. Therefore I wasn't sure what material to include to "reverse" that decision.

+1 on learning from this vote and discussion and trying to run a more general vote, but the question of scope is relatively open: should the vote cover bridges, instances associated with corporate interests, both, other?

See this part of the documentation for how this bridge implements opt-in:

How do I get started?

To bridge your fediverse account into Bluesky and interact with people there, search for and follow @bsky.brid.gy@bsky.brid.gy. That account will then follow you back. Accept its follow to make sure your

Fediverse posts get sent the bridge and make it into Bluesky.

And this for how to opt-out if you opted in but then changed your mind: https://fed.brid.gy/docs#opt-out

It seems very reasonable to me.

@Flancian

Keeping in mind that I would really rather not be discussing this on a case-by-case basis, in what way does the limit interfere with our users' abilities to utilize Bridgy?

My vote to suspend the instance outright (or keep the limit otherwise) aside, I wonder if it's useful having a discussion/vote on allowing posts to be slurped up by corporate social media in general? We've had this discussion and vote for both Threads and now this Bluesky bridge (slightly different as it's "unofficial", I know, but the result is the same). Maybe it's worth having a general policy for what to do by default, and then if something is special about a specific bridge we can always reconsider on an individual basis then?

Also, for everyone else here: sorry for never following up with a proper poll like I said I would; thanks for doing it Flancian!

I freely admit that I underinformed on this subject. I do think that opt-in should be the default policy for the community, so that we keep our marginalized communities as safe as we can while vetting any such bridge or link or whatever we call the pipes through which content flows into or out of our server.

I have evolvedy thinking considerably in the last several years, and there was a time when I would have assumed good intentions from all parties in a bridge or link, especially one created by a third party rather than by the service provider/corporation. But I no longer believe that we can have such a stance toward federation in the current social climate we inhabit.

So, this is a long-winded way of saying that we should keep the limit in place, and maintain a watchful stance on further developments. To do less is to be a disservice to our fellow members who need and deserve our support.

Should "Other" just be replaced by "Suspend/Defederate/Block"? What other possible options are there than limit, unlimit, and suspend?

@M. Page-Lieberman - jotaemeisocial.coop Good question, thanks! I think there are other possibilities :)

For example for me Other could have been "remove limits and do not limit other bridge instances proactively" as I am positive a priori towards bridges.

@Flancian I did mean to ask whether this is supposed to be a binding decision? If "Other" can just be any policy change related to bridges outside of this specific case it's never going to win even though one of those proposals might be what people would end up preferring. And if it did win we'd have to figure out what people actually wanted for their other, categorize them somehow, figure out which of those won, etc. and I'm not sure that it makes a ton of sense as far as voting goes.

Thanks for raising this and articulating a strong argument, @flancian!
As others have said, I don't think this proposal is well-formed. For instance, it requires people opposed to limiting the instance to vote for limiting it, even if down-ranking it.
Ranked choice can be useful for gaining insight on the relative interest in certain options. But for binding decisions in Social.coop, I recommend referring to this proposal-making tutorial on the wiki: https://wiki.social.coop/wiki/Main_Page

@Nathan Schneider thank you Nathan, we will redo it as such; I set this up quickly between other tasks to get the conversation going and I regretted using ranked choice almost immediately, I was too lazy to then copy/paste into a proper poll :)

@Sam Whited thank you for not blocking! I still don't see a good reason to block honestly. I have tried to address your concerns in the other comment 👍

@Dynamic thanks for your feedback! But I'm not sure blocking because of a rushed feeling is optimal; what kind of information or process would you need to feel comfortable removing the block? I thought I had incorporated all feedback necessary from the previous vote to make the vote well-defined, and I don't see currently what we should do with extra time. Could you suggest ways forward?

@Flancian

Is the goal to remove the limit, or to make sure that we're really collectively on board with decisions being made? I'm in favor of the latter, and I know that at least a few of us aren't comfortable with this decision. I want to feel like our priority is to have our actions reflect the will of our members, and these two proposals don't make me feel that way at all.

Only a very small percentage of social.coop casts votes on proposals at all, and any kind of accelerated process ensures that our decisions will be made only by those of us who have the time to drop everything, educate ourselves into having informed opinions, and then vote.

I have heard you explain repeatedly why your opinion is that admin of Bridgy is behaving well. I have not seen discussion of the harm inflicted by the limit, beyond a couple of Bridgy users making vague statements that removing the limit would make things easier for them.

I have, however, heard people express the wish that the limit were replaced by a block, and even indicate that they might leave social.coop if the limit is removed. That should be a red flag about a process moving this quickly. How do the other 94% of Loomio users feel about all this, let alone the large fraction of social.coop members who never set up Loomio accounts?

Meanwhile, handling this on a case-by-case basis seems to guarantee that we'll be doing this again in a year or six months or whenever the next question comes up about whether a new corporate instance emerges or someone writes a Threads bridge or whatever.

Here are some of paths forward:

• Develop a policy that defines criteria to evaluate whether and when corporate instances or bridges to corporate instances should be treated the same way we treat normal instances, and have the Technical Working Group apply that policy without needing to continually relitigate this.

• Develop a proposal that these decisions be handled by the Organizing Circle moving forward, defer to them in the future, and then in the future we don't need to continually relitigate this.

• Just leave the limit in place.

@Dynamic this proposal is only about removing the limit specifically because the limit is what is directly affecting my (and likely at least some others') intended use of my social.coop account to interact with parts of the Fediverse that don't contravene our code of conduct (unlike e.g. the fascist and troll instances we deal with on a regular basis when doing moderation). Additionally, limiting the personal instance of the developer feels actually kind of unwarranted IMHO and it makes me a bit sad to see social.coop remain in such a configuration.

Your sketches for additional proposals seem reasonable, and I would like to see all of the CWG, TWG and OC discuss these important issues and produce workable policy in this space. I just believe that these paths should not block what is actually a simple and well-defined vote.

Note there has been no democratic decision to limit the instance in the first place, so I truly don't yet understand why the onus should be so large on people seeking to remove the limit when the process was so light when we unilaterally limited earlier, based IIUC on incomplete or now outdated understanding of how the bridge works. Why not let the vote go ahead and see where we stand at the end of it? If you think the removal of the limit should not go ahead if e.g. >X% of the instance votes to keep the limit, that could be a reasonable thing to discuss.

But the argument could be flipped on its head and we could ask: why should we limit the bridge when it hasn't contravened our code of conduct, and nobody has voted for it? For all we know a majority or a significant minority of people in the instance would prefer having the option to use the bridge without degradation in its performance. So why are we prioritizing the wishes of one subgroup over the other? If the answer is 'the oncall made a snap decision and now limit is our default because a vote to revert needs to meet a very high bar of generality', that does not seem good enough. To me that seems to say that the wishes of people who want to prioritize not interacting with the bridge are somehow more important than the wishes of people who actively want to interact with the bridge. This is made worse by the asymmetry of the situation I believe, as people who don't want to use the bridge seem to have the following options even if we don't limit or suspend it:

• Do not opt-in whenever someone tries to follow them through the bridge.

• Ignore notifications from the bridge.

• Block accounts if somehow the above is not enough (I haven't learnt yet of a case in which it wouldn't be enough).

Whereas people who want to use the bridge as designed if we limit or suspend it have the following option only, it seems to me:

• Go to some other instance.

@Flancian @Dynamic "Note there has been no democratic decision to limit the instance in the first place" is a powerful point. If that's so, blocking the first democratic vote on limiting/not limiting the bridge because you view it as not sufficiently democratic seems in itself not-super-democratic? A 'rushed' vote to revisit a decision that was never voted on, seems better than no vote at all?

However if the block is just so that more time can be taken for more people to be made aware of, consider, discuss and vote - that also seems reasonable.

@Nic

YES. The block is to slow this process down. People need to be able to understand what the are voting on, and also we need to create space for voices to be heard and for people to reflect on what one another are saying.

@Dynamic are you proposing the vote be extended, or that a different format should be used to debate things? I'd support the former, but the latter, while the Loomio process obviously has shortcomings - as the only system we've been using until now it doesn't seem right to change it mid-vote? As a separate thing to focus on, yes - how to ensure everyone who wants to vote can, and gets enough time/information to do so, seems something we could answer much better. I have no idea, for e.g. what % of coop members get the Loomio emails, or what % don't know about Loomio but would want to be here.

Parallel to this - as all that is being changed is adding the ability for people to opt in to something that some (like me) would find useful, the argument against it seems to boil down to trusting if the developer of the bridge is honest and has learned their lessons - or not. Will a bigger, wider debate help people make that 'gut feeling' choice? Most of us can't know - a lengthy prosecution/defense of their actions until this point won't change something that's ultimately a trust issue. Given that if they breach that trust, they can easily be blocked again – is this as significant as vote as, say, limiting Threads, or extending the posting character limit?

@Nic @Dynamic thank you for discussing this! I have extended the vote for another four days, for a total of ten days (plus the three days for the previous/dropped vote), to try to make it more inclusive and allow for further discussion as necessary.

@Flancian, is there a reason why you can't add the language that I suggested?

I don't thing that adding a clearly labeled edit explaining that in response to member concerns you have spoken with the bridge's developer and confirmed that users who have not opted in are completely invisible to the system would substantively change the proposal beyond making it clear to people like me who had no idea what the broader context was that this is actually benign.

The proposal as written still points exclusively at a documentation page that in my opinion is unclear.

@Nic

The problem isn't Loomio, and it isn't that there are any problems with the action being proposed... now that I (mostly) understand the issue.

The problem is that I needed to do extensive research, including getting @Flancian to talk to the developer about how exactly the bridge software behaves, *to even understand what we were voting on*. I don't think most people have this kind of time to put in. Really, I would be better off if I hadn't put in that time myself.

For people who use Bridgy every day, the proposal might seem very easy to read and straightforward, but for those of us who don't, and who don't use bridges more generally, and who haven't thought about this since February (if at all), the two proposals were not easy to understand. Even just knowing what a "limit" does on Mastodon takes a certain amount of research. For people who don't use bridges, it isn't clear what bridges do. Even for people who understand limits and bridges, it isn't obvious why a limit would cause special problems for a bridge. There's a lot that's counterintuitive about this situation.

When I got to the polls number of people had already expressed concerns. And a I believe a number of people had also stated, in their vote, that they didn't feel they had enough information to form an opinion. We have no idea how many people looked at the poll, thought "I don't have time to figure out what this is about" and walked away.

By the time I got to the second poll, I think that @Sam Whited (who is probably one of our best informed members on this issue) had already brought up that the process felt rushed, and had in fact already suggested that the second proposal should be blocked. I may have misread, but I think his main reason for not blocking was that he felt it wouldn't be right given that he had imposed the limit in the first place. That is not the situation that I am in.

As far as I could tell, these concerns were not taken as a signal to slow down at all. The non-responsiveness to Sam Whited's concerns added to the feeling that this was being rammed through as if our highest priority is to remove the limit and not to listen to what our members are saying.

All of this aside, I don't think it's correct to frame a block as preventing "a vote from going forward" on an easy, straightforward question that reasonable people would agree on. In a vote that is actually that straightforward, I think it shouldn't be hard to get the supermajority required to override the block.

The purpose of my block is not to keep the limit from being lifted, but to ensure that people don't need to do hours and hours of outside research in order to cast a vote on what to do.

At this stage, I think the ideal thing would be if language were added to the proposal explicitly stating the problem with the limit (i.e. that it prevents our Social.Coop Bridgy from getting notifications of interactions with Bluesky followers that they don't yet follow) and that we have confirmation from the Bridgy developer that (even without the limit) Social.Coop members who have not opted in to Bridgy will continue to be invisible to Bluesky users.

I'm not sure if there's are technical or policy problems with editing an ongoing proposal in this way. Socially, it feels like it shouldn't be a problem to add an informative note if the rest of the text of the proposal is left in place, but if there are reasons this cannot be done, perhaps we can talk more and find another solution.

@Dynamic thanks alot for that explanation, it makes a lot of sense. Adding more context to an open proposal seems to me ok, provided this doesn't change the essential question and it goes in the daily Loomio email this has happened, given people can change their votes. (FWIW my problem with Loomio is I never get email notifications of comment replies so have to remember to scroll back to find them!)

@Dynamic the reason I didn't add the information yesterday is that I didn't have the time to review and take action on every comment in this thread. It has been added now.

On the block, https://wiki.social.coop/wiki/Make_a_proposal currently points to Bylaws which says this:

"A Block vote represents a fundamental disagreement—a belief that the proposal violates Social.coop's core principles."

This is what made me push back against your block, as I didn't understand which core principle was violated by starting this decision poll.

@Flancian

I apologize if there are things I could have done to make it clearer that my block was based on process, not based on the substance of the proposal. There are a bunch of things that bothered me about the early stages of the two proposals.

@Sky Leite hi and thank you for your feedback! Could you clarify, if you have the time, what do you mean with 'I'm willing to leave the co-op if that were the case'? The bridge is opt-in, in the sense that it seems designed not to cross-post anything to Bluesky before the user has explicitly opted in by following the main bridge account.

I fail to see how this is wrong and could result in you leaving the coop, unless there's a confusion of terms here. As is, with opt-in you should be able to ignore the bridge (not take any action) and your privacy/data ownership would be fully preserved. Opt-out would be the base model in which you would have to take action to prevent data from flowing; but this bridge offers opt-out only as a way to cancel bridging *after you opted in*, not as a "base model" for consent.

@Flancian I see! I initially assumed the opt-in would only apply to receiving BlueSky posts, but from your explanation it seems that would also apply to my own posts being cross-posted to BlueSky.

If that's the case then I don't see an issue. Thanks for explaining. I'll change my vote to "abstain", since at this point I don't particularly care either way :p