@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:

@[email protected] @[email protected] @[email protected] 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

@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 @[email protected]. 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

Follow up:

I think we should put a pause on this until we've actually discussed what we're voting on, how the issue is framed, and until we're sure we have all the information about the bridge.

Normally I'm not the type who wants a long discussion about how we're going to vote on something, but I find the framing of this issue and the odd rapid-fire voting process a bit off putting. If there were problems with the poll the first time, we should probably discuss how to do it not just make another poll in a slightly different way which may or may not be better.

I'm also a bit uncomfortable with the framing of the issue. The statement that the bridge "should be treated as our instance treats any other instance in the Fediverse by default going forward" seems wrong to me. It's not like any other fediverse instance. Even if we agree that it is, any other instance would be limited or blocked for the sort of consent issues in the authors original post (and this would be done at the mod teams discretion, we wouldn't be seeking a vote on it). So I don't think we are treating bluesky like any other instance, and I don't think we can, this is very misleading and puts things in a positive light that I don't think they deserve.

The other option says "they are special cased (which means limited visibility for people using the bridge, and the possibility of missing notifications from bridged users even if you are interacting with them directly)", the idea of "special cased" aside (same idea as the previous paragraph), I don't think limiting visibility means missing notification from bridged users even if you're interacting with them directly. If it does, it's unclear to me exactly how. To interact with the profile you'd have to go in and show it, to interact you'd have to follow the user, which effectively undoes the limit for your specific account. I may be wrong, but the question doesn't explain how all this works well enough to make an informed decision. Even if I am wrong, we're presenting downsides only for the No vote. I don't see anything about the problems with corporate social media and why a Yes vote might be a bad idea.

And the last thing about the poll: if we're deciding what to do going forward we should present all the options, not just two of them. This is framed as "vote to undo the previous decision", but it equally could have been framed as "vote to ratify the previous decision", which I think would have been equally a problem, but maybe shows why I'm uncomfortable with this framing? We're missing some options here. For example, we also have the option to suspend the bridge, and while I don't think users will choose that, it feels odd to leave it out and bypass any discussion of other options and only frame it in terms of the previous vote.

It's also still unclear to me whether with the bridges new opt-in rules if consent is only required to let someone follow you (a good first step) or if my public posts will still be slurped up into bluesky where they can be seen by folks not following me. Until this is cleared up, I believe this proposal should be blocked (but won't do so myself as I see this as a conflict of interest and am not sure that anyone else would agree with me).

All that being said, thank you for following up with a vote. I said I would, and I forgot, so I owe you and the community an apology for not doing that. I don't want to delay this unnecessarily, and I also didn't do this correctly the first time, so take this all with a grain of salt.

@Sam Whited Thank you for your comment!

1. By 'treated as any Fediverse instance by default' I meant the set of users using the bridge, which are strictly a subset of Bluesky and Fediverse users. I think it's reasonable to model them as an instance given that e.g. they will all share a domain name in their interactions. Anybody could set up a Fediverse service backed by any kind of database; as long as they speak ActivityPub, we wouldn't even really know they are not vanilla Mastodon and we wouldn't care unless their users break our code of conduct or are otherwise abusive. Which hasn't happened here.

2. I have seen the surprising notification behavior myself. I tried interacting with @snarfed.org, they responded, and I didn't see the response at all until the developer pinged from their @indieweb.social account to let me know I probably wasn't going to see it because we had limited them. It felt like I was cut out from these domains, which I am, without any kind of UX warning; and it makes social.coop less usable for me day-to-day.

3. There is always going to be a framing problem when we have a yes/no decision, but I heard feedback after the previous vote that yes/no was preferable. Note that the previous ranked choice vote, even though it was confusing and I wouldn't try it again for such a situation, worked around this issue as people had to rank 'remove limit' and 'keep limit' explicitly. I think framing the vote with yes="keep the limit" would be acceptable, and if anybody else had set up the vote that way I wouldn't push back against it.

4. The concerns with the 'rapid-fire' voting process need to be put in context: first, on a personal level, I only have a few hours I can dedicate a week to social.coop usually, so for me it's either Doing Stuff or focusing elsewhere, and I Do Stuff hoping it will at least help bring the conversation forward. Having said that, this is a second vote incorporating feedback from the previous, and it runs for six days in itself, so hopefully an end-to-end process lasting nine days to undo a unilateral decision taken without a poll six months ago should not blow anybody's socks off? :)

5. Finally, if you want a vote to suspend or explore other options, feel free to set one up, but I don't think that is a sufficient reason to block this vote. Surely if people want to suspend, they will clearly vote to limit for now; and from there the cooperative can move on to a suspend vote if limiting is not enough for you.

"The concerns with the 'rapid-fire' voting process need to be put in context: first, on a personal level, I only have a few hours I can dedicate a week to social.coop usually, so for me it's either Doing Stuff or focusing elsewhere, and I Do Stuff hoping it will at least help bring the conversation forward."

I don't understand this urgency at all. Is anyone being harmed by the limit?

The rest of us are busy too. The fact that you only have a few hours a week to dedicate to social.coop does not mean that the rest of us should have to drop everything and re-research what the bridge even does and form an opinion about it without even a straw poll to gauge interest.

@Flancian
I really really do not have bandwidth to research this, but if there is anything to @Sam Whited's concern about public posts being slurped up and cross-posted onto corporate-run instances, I think that is a big problem, yes. I'm not interested in adding to the user experience for people who opt for BlueSky over the open web.

I'm also not interested in switching to only "followers only" posts, which are honestly a pretty terrible model for a bunch of reasons.

@Dynamic IMHO yes, the limit causes bugs when interacting with bridged users (see point 2. above); it causes social.coop users to not see any Bluesky activity, even when people are actively trying to interact with the Fediverse, and so miss out on opportunities for connection; and it causes Bluesky users to not be properly exposed to our instance and any others who follow our example, with the result that it partially locks them out from the Fediverse and makes them less likely to become or remain involved in the network. It also may hurt the developer, as we have blocked his personal domain as if he was a spammer for providing a service some people take issue with, even if it's opt-in.

@Sam Whited, could you clarify why you believe Bridgy Fed will break its apparently stated way of functioning and start "slurping posts" or otherwise subverting users' expectations?

I am not aware of a standing policy in social.coop that says that we will not federate with corporate interests in any way, or that we will block bridges. I do not understand why voting with supporting information, which I have included inline in this vote, is not enough to potentially (if the results pan out that way) undo a policy decision made provisionally and without a vote by the community working group oncall six months ago. You ask for more time, but I would like to understand what you would like to do with that time, and why social.coop users like myself must stand idle in a status quo we did not vote for and (in my case) do not prefer.

@Flancian

This is what the Bridgy policy says about what content will be visible on Bluesky:
"Who can see me and my stuff?

• Only the people who can already see you and your stuff, without bridging. Bridgy Fed only bridges fully public data, so if your account is private or protected or followers-only, it won't (can't!) bridge your account at all. Same with DMs and private/followers-only posts; it ignores those."
  
  I might be missing something, but this sounds to me like the person making the statement regards all public posts as up for grabs.

The absence of a standing policy about how to handle corporate instances is exactly the problem, yes. There should be one. We don't have it.

@Dynamic @Flancian this FAQ entry and the fact that the website seems a bit light on details (and is confusing, I'm still not sure which thing is which since there are two identically named products that appear to work differently somehow?) also made me wonder if the author had actually addressed the initial pushback to their blog post.

@Dynamic I have included inline in the vote the opt-in section I believe is key to parse the documentation, which is:

To bridge your fediverse account into Bluesky and interact with people there, search for and follow @[email protected]. 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.

TLDR: I believe the section you quote is assuming you have opted in as per the above.

@Flancian

I understand that that is one way to read the text, but it isn't unambiguous. I would like explicit confirmation, either through software testing such as Matt Noyes has been doing, or through discussion with the developer (which I think you were pursuing?), that Mastodon content can only end up on Bluesky via the bridges if the author of the post has taken a positive action to ensure that it can end up there.

@Dynamic this has been confirmed by the developer, see below.

@Dynamic a debate on policies for the corporate web seems a separate issue. It seems like approving Bluesky to be treated as any other instance here would allow individuals to make a call for now, informed by this discussion if they participated.

Is it normal process for us to not be able to see votes until after we have cast a vote? It feels weird, but possibly that's because we normally have a chance for discussion before a proposal is even made?

@Dynamic I think so? I used the default governance template for yes/no questions.

Update: the second vote has been blocked for a "rushed feeling". At this point I am considering dis-engaging from this issue as it feels like we have entered a tar pit. Unfortunately I do not agree with the fact that reversing a unilateral provisional policy decision apparently takes more than two votes spread over nine days, six months after the fact, even though the latest vote (which I set up in quick succession to the first one to incorporate feedback and address criticism) is provisionally showing that a majority of social.coop would prefer to remove the limit; and we could always have another vote if new information comes to light or if the community wants to put some different policy up for a vote.

I will wait for answers to my requests to more information, but in the meantime will be considering next steps w.r.t. my engagement with this issue in particular and social.coop in general.

@Flancian WRT to the original unilateral decision, that's a fair criticism and I apologize. I had meant to give us time to do some more research and then hold a proper poll, but I let the ball drop there and it turned into 6 months of a thing I just did being the de-facto policy.

I hope you won't consider disengaging from social.coop because of this; you're a valuable team member on the CWG team and we all enjoy working with you. Democracy is messy sometimes, and I think we're all mostly just worried that there wasn't time for discussion and understanding the issue first. As you said though, we can always do it again later, whether that's first clarifying a few things for the person who cast a block vote, or whether that's coming back and re-voting to limit or suspend the bridge if we find out the author is doing something we don't like.

@Sam Whited thank you, Sam! I appreciate that, and likewise.

I would indeed consider leaving social.coop if we become isolationist or what I term internet-xenophobic, meaning a community which is uninterested, unwelcoming or actively hostile towards people who use a different protocol or are stuck in corporate instances, or people who are interested in outreach to those people. I would at least likely stop my engagement in working groups partly or fully as I'm interested in doing work to improve the Fediverse and make it more inclusive, diverse and vibrant; and such an instance wouldn't embody those values sufficiently in my opinion.

@Flancian Understood. As is possibly obvious by now, I tend to want to achieve the same goal of making the fediverse a more inclusive, diverse, and vibrant place, but I think the way we do that by the opposite means. That is to say, by protecting our users from bad actors and not being a "growth at all costs" network like the large corporate networks. I don't think we have to be hostile towards people using a different protocol or instance, we're just limiting them so that they can't spam our users or slurp up their data without asking first. That seems like a good way to ensure everyone is safe and happy and we don't invite the same kinds of abuse that are widely present on the major corporate networks and makes us a safe place for people who may have been threatened on big corporate networks in the past.

@Sam Whited I'm glad we share similar goals! That makes sense of course.

Furthermore, I think there is definitely room for one or many conservative instances in the Fediverse, meaning instances willing to risk over-limiting or over-suspending to protect users from as many attack vectors as possible. I think we are just not fully aligned in social.coop being that kind of instance. I for one do not identify as a conservative in this regard, and would love to see social.coop remain well-moderated but clearly liberal and as open as possible by default.

@Flancian thanks for raising this. I am a community organizer on surveillance issues and I don't think I could actually stay here if I can't bridge my public posts to the fediverse because people won't get information they need, or if have to build a coalition with people from lots of different instances to post across instances since I can't broadcast.

I understand there's a fundamental tension between two ways of achieving this goal.

Wouldn't a way of resolving this tension in terms of political strategy be to involve the open web movement in work to pass a law that prevents said slurping? Or could we create a content license for our posts that is non-commercial only and then organize the resources to legally enforce it?

Information questions:

1) If someone on BlueSky who uses Bridgy does a search for a Mastodon user who does not use Bridgy, what happens?

2) If someone on BlueSky who uses Bridgy attempts to follow a Mastodon user who does not use Bridgy, what happens?

3) If someone on Mastodon who uses Bridgy boosts the public post of someone on Mastodon who does not use Bridgy, does the boosted post show up on BlueSky?

(Edited to correct a minor typo)

@Dynamic I will ask the developer directly and relay back the answers.

@Flancian Thank you!

@Flancian
TY :D

This will help inform more of us, so we can make a more balanced decision.

From a personal perspective, i was of the "feeling rushed" situation, and that's because i didn't have the time to understand what i was being asked to vote on, before the vote was due. :D

How to deal with this situation in future will be part of the larger conversations about how we do things, though the way that this was done was handled well, up until the "rushed vote". :D

As for the larger conversation around the bridge:

There are a few people that i met via Twitter, who i would still like to talk with, who are now on Bsky. I got a Bsky invite from one of them, but i didn't want to jump from one corporate platform to another.

At that time, i couldn't persuade them to move to Mastodon, as i wasn't able to communicate with them about it effectively, as i was still learning myself..

Letting them see some of the conversations here, will help them see that this will be the better option.

Even though i am not it's target, i am really aware of how some of the racism was carried over from Twitter to Bsky, and i don't want things to become any worse for anyone else here.

A better explanation of how this style of bridge will operate would be really useful, as well as a clear explanation, of how Bsky's moderation operates, and how this will affect the workload that will hit our moderators. :D

@Billy Smith

Thanking for chiming in to say that you have also felt rushed by the way that these proposals were put forward. I am currently licking wounds about the fact that I blocked the current proposal for this exact reason but most of what I've gotten back has been Flancian objecting to my "not letting the vote go forward."

I want to reside in a community where there is a culture of building consensus. I've been feeling the opposite of that, and it hurts.

@Dynamic I reached out to the developer and they got back to me with the answers to your questions:

"1) They see nothing. Bridgy Fed doesn't send anything from a given Mastodon user to Bluesky until they opt in, including their profile.
2) Same. The Bluesky user won't be able to find the Mastodon user - they're not in Bluesky at all yet - so they can't follow them.
3) No."

My apologies for pushing back against your block in a way that hurt you! It was not my intention. I thought if blocking a vote was fine, then pushing back against the block would also be fine. But feel free to block as much as you need of course, and I'll make sure not to question blocks so freely in the future.

@Flancian

If you can edit your proposal to clearly lay out 1) that there is buggy behavior caused by the Limit, and 2) that you have confirmation from the developer that users who have not intentionally followed the bridge will be completely invisible to the bridge instance, then I will lift my block.

@Flancian

Thank you for apologizing.

If you want, I'd be happy to talk more with you about why I wasn't feeling good, but I'd prefer to do that in a more private space. Or we can drop it.

@Dynamic I will edit the proposal now, making it clear that it was edited on 2024-09-10 adding this information. The buggy behavior (w.r.t. notifications) is already mentioned in the vote currently so it doesn't need to be mentioned further I think.

@Flancian

Thank you. I have changed my vote. I would have preferred to make it clear that the answers came from the author of the Bridge software, but this is acceptable.

I think I'm missing something. Are Social.Coop users currrently able to follow accounts and accept followers through bridgy? As I understand it, if an instance or user is limited by Social.Coop, our users can still follow and be followed by them. Limit just means a) I have to find and follow them and b) their posts will only show up to people on our instance who follow them. Is that right?

https://docs.joinmastodon.org/admin/moderation/#limit-user

https://docs.joinmastodon.org/admin/moderation/#limit-server

Yes, as far as I know this should not stop anyone from following users on bluesky instance, they would just have to hit the "Show this Profile" (or whatever it's called) button first. The problem would be if someone on bluesky tries to message or follow you, then you wouldn't get a notification, I don't think. You'd have to follow them first or they couldn't engage with you.

@Sam Whited That makes sense. I can see why people eager to engage with bluesky users would see that as overly restrictive. It would be great if users could identify themselves as open to bluesky user contact...

@Matt Noyes I think the bridge author may have updated it to work that way after the initial push back against automatically bridging everything. It's still not completely clear to me though; I think @Flancian is asking after another user also asked for more information.

@Sam Whited I just searched @bsky.brid.gy in Mastodon and got a list of accounts with the "show this profile" button, as you said. So it seems the only issue is that bluesky users can't use the bridgy app to find people on our Mastodon instance, due to the limit. I wonder if someone who has accounts on both could test that? @Nathan Schneider ?

Thank you for doing this legword, @Matt Noyes. I think it is very important that multiple people be doing research on what is actually going on with the bridge, so that those of us who have no idea what Bridgy even is can cast informed votes as to how the bridge should be moderated.

@Matt Noyes Been doing some experiments with the bridge myself after I migrated to social.coop. On my 1-person instance it was working fine, but here I'm observing some weird stuff: I can't actually follow Bluesky from Mastodon (a "follow request" is shown) and my posts from Mastodon don't appear on Bluesky. If needed I can try to do more debugging.

@Matt Noyes hi Matt! Thanks for looking into this!

Following individual users works for me but interacting with users without previously following them doesn't, in two ways, one obvious and another not obvious:

1. You can't really see the bridged users or their posts because of the limit, so it's hard to find them and follow them in the first place. This is the obvious one because that's sort of the definition of limit (which doesn't make it correct in this case, though).

2. If you find a user and attempt to interact with them but forget to follow them at the same time, you will never see their replies (no notification takes place). I was hit by this, which prompted me to look again into this issue and start the vote(s).

Note also that we have limited not only the bridge domain but also the personal domain of the developer, so on top of the bridge disruption any social.coop users who want to interact with Ryan Bartlett are also affected by our limit; IMHO for no good reason.

@Flancian

In addition to everything else that had not been clear to me, I also hadn't realized that one of the limited instances was a personal domain. When you expressed concern about it previously, I'd thought you were saying that the bridge domain was the same as the personal domain which hadn't seemed to change things.

FWIW, if that was just the authors personal domain I apologize, that shouldn't have been part of the limit. My understanding was that the bridge was running there at the time, but I could have been wrong.

EDIT: and if the bridge is not running there, we don't need a vote for that one, feel free to just unlimit that if it was an innocent domain that just got accidentally limited by me.

@Flancian I'm not sure what you mean by you can't really see them. I just searched @bsky.brid.gy and I can see bsky users, their posts, posts and replies, and media. The fact that you have to follow someone to see their replies doesn't seem like too big a burden and seems fitting for a limit. I still don't understand how the limit -- beyond doing what limits do -- interferes with your use of bridgy?

@Matt Noyes ahoy! Thanks for following up on this.

1. You're right in that searching for @bsky.brid.gy or user handles works better than I thought it did, thanks for correcting.

2. I respectfully disagree that having to follow someone to see their replies is not too big of a burden, as it is silently and fundamentally breaking expectations. If Mastodon showed a warning that you might not see replies it might be OK, but it doesn't, and this bit me and is likely biting other users all the time.

3. Beyond this, I just saw that @Juanlu reported issues with following bridge users in https://social.coop/@astrojuanlu/113113817065751404, and I am seeing similar issues when following bridge accounts. I'm still unsure this is due to the limit, but it might be.

@Sam Whited thanks for the follow up on snarfed.org. I checked and https://fed.brid.gy/web/snarfed.org makes me think Ryan is using Bridgy there, but not Bridgy Fed. This means he has a Wordpress site that is showing up as an instance thanks to his other bridging project, which in this case only bridges to his personal site. I see no reason to limit that so I agree we should just remove the limit.

@Flancian @Matt Noyes
I do think it's worth noting somewhere that bridges are kind of by their nature quirky objects trying to patch together services that are not designed to interoperate, so in that sense, buggy behavior feels sort of inevitable.

I therefore don't think that in the general case "ensuring bridges behave as expected" should be enough reason for an instance to change moderation levels if there are other reasons to keep the moderation levels in place.

In this specific case, there doesn't seem to be any major risk associated with lifting the limit, which gives the convenience aspect more weight than I think it should normally have.

After receiving feedback that a six days vote is too quick, I have extended this vote for an extra four days, for a total of ten days. This also gives people an extra weekend to catch up with coop affairs and vote, which I hope will make this vote more inclusive.

Given that six days was considered too short for such an issue, even after a previous vote that took three days, I would suggest we change the default governance template. But that can probably be the topic of a different thread.

This thread is relevant as it discusses the moderation problems that we will face:

https://cyberpunk.lol/@vantablack/113133448621534708

:|

First time participating on a Social Coop proposal - It is my understanding that this has now passed, right?