Discussion: Support the Anti-Meta Fedi Pact

Maybe everyone is sick of talking about this but I've been trying to wrap my brain around this issue and I think I'm finally starting to get it! Please let me know if I've gotten anything wrong. (This is only about moderation, which is my main concern.)

If Server X has weak moderation and becomes a haven for bad actors, then we block the server because that is much easier than playing whack-a-mole with all the bad individuals.

The interesting thing is what happens next: all the nice people on Server X move to servers with stronger moderation. In this way, the fediverse naturally separates the bad actors out onto islands where they don't bother the rest of us.

The problem with Threads is that, because it's so massive, it's physically impossible for all the nice people to move to other servers. The sheer size of it breaks the fediverse's natural sorting function.

Thus, it seems we have two options: block and accept that Mastodon will continue to be a niche player, or federate and accept that we will be playing whack-a-mole for the foreseeable future.

Of those two options I prefer block, but then there is that other question of limit or suspend. I believe limit is sufficient to save us from playing whack-a-mole while still allowing us to connect with our friends, so that seems like a reasonable approach to me.

@Brian Vaughan - that's a really complex process - and I don't understand it myself. I would consider it a measure of opinion rather than a binding vote. The rules need to be decided before the vote, not vaguely interpreted afterwards.

I think it's worth considering the feedback and coming up with a single proposal of action for people to vote upon.

In terms of meta discussion, (as a Loomio dev) I can see how it would be useful to reply to the the Outcome statement.. and for the outcome to feel like a milestone in the thread that new conversation comes from.

Very much agree with Robert Guthrie. It makes sense to have an up or down vote on a single proposal that integrates the concerns raised as much as possible.

This would be the sociocratic way: all voices are integrated in a proposal that then each person objects (meaning "I see a possible danger") or consents (meaning "maybe it is not my ideal but it is good and safe enough to try").

If there are objections then that proposal needs to be worked more.

That proposal should include the measuring criteria for success (we can achieve B..., We evade Z...), maybe some of alarm (if X climbs over Y then we...) and a specified duration to maintain. At that time (if no alarm is triggered before), the results will be reviewed.

Once it has everyone's consent it is carried out by the relevant circle, working or operations group.

@Robert Guthrie I think consensus to block Meta is demonstrable by this second vote. It's an increase from the previous vote of 51% support to block and sign the pact. A further vote empowers the time-rich (not working single mums, for e.g.) and given there's 56.4% supporting some form of defederation - including from the person whose block could bizarrely see us end up federating - I'm not sure another vote is needed other than to fine tune what exactly 'defederate' means (how long / what statement / what rules to justify / etc).

@Nic - I have no opinion either way. I'm just saying it's the most confusing voting method I've ever seen. To me, this isn't a consensus outcome, it's still somewhere in the middle of the process.

Edit: And I think as a group you need to preserve/nurture your decision-making process, more than you need to come to an outcome on this decision, in the short term.

@Robert Guthrie I guess it's a good opportunity to improve decision making as it's clearly rusty, many care about this, and maybe the urgency isn't what we thought, as Threads isn't trying to federate yet.

@Nic - nice noticing on my language. I guess I'm only just stepping in - and don't fully consider myself part of the 'we' yet. My comment was based on my experience supporting groups using Loomio, rather than being a member of this group.

I'm a paying member but not much of a user so far. I don't yet have personal attachment to social.coop - but I'm really fascinated from the perspective of Loomio developer, wanting to better understand how you/we are using Loomio and how I can improve the experience from this seat.

@Robert Guthrie it's really great you're engaging with how we're using it. I hope you don't mind me sharing some thoughts!

A discussion and two votes this long does become quite hard to navigate, while the infinite scroll means I can't always do text searches to find a name/phrase. I appreciate the right-hand menu is trying to address that but that itself is longer than my browser height and vanishes on phone. A small table of contents (vote 1/conclusion 1/vote 2/conclusion 2/general discussion) top left/right might work? On my phone I was trying to jump thru the comments to find whoever had done the block and it drove me a little crazy as the infinite scroll would get me so far then take me to someone's profile (always the same person!).

Another thing that stood out after I submitted the ranked vote was that two options displayed next to my vote weren't my top two. It took me while to realise there were numbers next to them indicating their rank, but my instinct is it would have sorted those results so my top two choices appeared top.

Also, as others note, we couldn't drop some items from our rank, so people gave points to positions they didn't support. Some of these then got multiplied by 9! That might be quite specific to us, but in this case if there had been some way for 'block' logic to be configured in the build of the vote, if someone blocks before the vote closes, it becomes clear to the community that this has reversed the current vote and more discussion/rethinking might be needed.

@Brian Vaughan Not sure how to reply directly to the outcome, but this passage struck out:

So my reasoning is that a multiplier of nine would be applied to the point total for Option 4.

Since this was a ranked choice, meaning Option 4 couldn’t be unselected, applying a multiplier of 9 would place it as a default win because the top selected option is only worth 4 points.

@django I have no idea how to score this. For one thing, Loomio's scoring method for a ranked choice vote doesn't resemble the details I've seen elsewhere for how ranked choice voting is supposed to work. It didn't allow for not voting for an option at all, for instance.

It's possible I misunderstand, but it sure seems the weighting makes the poll worse than pointless.

@fm2279 I think this depends on your perspective. I'm not sure how much experience you have with coops in general, but some coops make decisions by full consensus (I've been part of a worker-coop like this) meaning that 100% of coop members need to be on board with a proposal or the status quo wins. This isn't practical for most large coops, but if that's your baseline, social.coop's modified version of that where you need 90% support for controversial decisions actually seems fairly lenient. (I do agree that RCV doesn't play super well with this system.)

This is why in Sociocracy the power to decide and execute is distributed in smaller circles that are closer in knowledge and action to where the discussed issues are.

Of course, there is also a general circle, with 2 full members of each circle. This is, they are not only representatives, but members of the general circle and other circle/s at the same time.

If here in social.coop a general assembly is too much people to decide with efficiency we can organize around circles.

But this is not to take this decision right now, only something to organize in our (possible) future...

I think this type of split has already happened once in social.coop? It seems to me that the more cooperative instances there are in the fediverse the better, especially if they are federated in more than just a technical sense?

@Ed Summers

Wait, did social.coop and sunbeam.city used to be one group? Is there a written history of this somewhere?

Interesting notion. I wonder if "polities" could be split while "infrastructure" remained "commoned". In practical terms could this mean an experiment in common tech labor and revenues?

Persynally I am more motivated to defederate from Meta less because of a negative (threat) and more because of a positive affirmation: I want to be in community with people who want something other than the social logic Meta offers.

Feeling that erosion..

It was a bit before my time but I believe that there was a disagreement early on that led some people to leave social.coop and head for other places like sunbeam? I'm not sure if a history of it lives on here in Loomio, and seem to remember the use of Loomio might have been part of the debate at the time? I might have totally just made that up, so take with a large boulder of salt.

For clarity, how do people feel about another vote to be in line with the by-laws and try to be crystal clear (third time's the charm ☘️)?

In the event that Meta's Threads joins the Fediverse and begins using ActivityPub, social.coop will:

1. Defederate (suspend) from all Threads servers

2. Do nothing

3. Block

Apologies for changing it up mid-stream, but looking at the proposal guidelines again I think it needs to be reformulated:

In the event that Meta's Threads joins the Fediverse by using the ActivityPub protocol SocialCoop's Mastodon instance at social.coop will defederate by suspending all relevant Meta host names.

While there are potentially many reasons to defederate from Threads, the primary motivation for this decision is to limit the degree to which data flows automatically between SocialCoop and Meta because of their track record of reselling user data and inability to promote cooperative social media conversations.

1. Agree

2. Abstain

3. Disagree

4. Block

Please see the rules for proposals for help understanding the significance of Block.

@edsummers Looks reasonable. We should definitely get the more experienced parliamentarians to check in about the form of it.

Paging @Nathan Schneider @Matt Noyes @Matthew Cropp @emi do

@Ed Summers I think it makes sense to do an up or down vote on the single proposal as you formulated it. It it fails, people can make new proposals (e.g. limit, wait and see, etc.)

@Ed Summers rephrasing slightly

1. Defederate (suspend) from all Threads servers

2. Wait and see *

3. Block proposal

* Federation was planned for 3 months after launch, we could conduct another poll say 1 month after this, perhaps with input from our Moderation team.

@Django It goes without saying that we can always make new collective decisions in the future. The goal of this proposal is to draw a line in the sand for now, and not keep punting into the future.

In re-reading the rules around proposals I needed to adjust it a bit. Let me know if you still have suggestions!

Does it make sense to make them:
+ Defederate (suspend) from all Threads servers
+ Limit (option added)
+ Do nothing
+ Block

Sorry if it was explained before and I lost it, but what's the difference between block and defederate?

Thanks...

@Eduardo Mercovich thanks for the reminder to look at the Proposal rules again. I've made some revisions to my original proposal. See if you still have questions about them?

@Eduardo Mercovich

I think it's hard to get coherent data when we offer three distinct options. The last two times we did this, it really seemed like people were reading into the poll results what they wanted to see. I also would really really like to have a supermajority to decide how to move forward with this thing. That might not be possible, but I firmly disagree with settling for a plurality.

yeah, I think the 'Do Nothing' poll item doesn't quite represent the stance. It should be more like "Wait until they break our ToS and THEN defederate"

@Dmitri Z. I have since updated the proposed text. Do you still have the same concern about how the proposal is phrased?

@Ed Summers thank you for following up / checking! I can't actually tell where the updated proposal text is -- this thread is way too dense!

@Dmitri Z. Yeah it is almost impossible because parts of the thread get collapsed. I think this link should take you to it, if you look just underneath the now struck through text? https://www.loomio.com/d/AZcJK6y2/discussion-support-the-anti-meta-fedi-pact/315

The problem remains that the bylaws assume a straight agree or disagree vote on a single option.

@Brian VaughanI agree. I liked @Ed Summers original proposal as amended by @Django. I see multiple options before us.

Been pondering this more. I think we should separate the decision of whether to Suspend / defederate from Threads.net from the question of whether to Limit the instance. I think it is likely we could achieve broad consensus on Limit-level moderation, while leaving open the option of full defederation as a future proposal.

I'm not personally happy with the idea of stopping at Limit, and might leave social.coop if that's what we're stuck with, but I think it would be foolish for us not to take positive action to moderate Threads.net.

(these thoughts partly inspired by the thread about Sociocracy here: https://social.coop/@nicol/110711778899925711)

With that in mind, how about a proposal worded something like this:

Proposal: Social.coop will moderate Threads.net at a minimum of the Limit level.

As described on the Mastodon documentation page on moderation tools (https://docs.joinmastodon.org/admin/moderation/), limiting an instance is "Equivalent to limiting all past and future accounts from the server. Previously known as “silencing”."

That is to say, that it is an instance-level moderation tool that has the effect that:

A limited account is hidden to all other users on that instance, except for its followers. All of the content is still there, and it can still be found via search, mentions, and following, but the content is invisible publicly.

At this moment, limit does not affect federation. A locally limited account is not limited automatically on other servers. Account limitations are reversible.

This proposal does not preclude future proposals to Suspend (defederate from) Threads.net entirely.

Proposal options

• Agree - Social.coop should Limit federation with Threads.net

• Disagree - Social.coop should not Limit federation with Threads.net

• Block (? - I'm unclear on how to best structure a proposal to allow for blocking)

@dynamic I think this is a good statement of the question.

When you create a poll, there's a template for polls for Social.Coop that uses Agree, Disagree, and Block. So I think that would cover it.

@Brian Vaughan @Dynamic I like the options expressed this way too with the template. But I find the language of "Proposal: Social.coop will moderate Threads.net at a minimum of the Limit level." to be confusing. Who will decide what level will be implemented if people agree?

@Ed Summers

How about "Proposal: if Social.coop federates with Threads.net, Threads.net will be moderated at the 'Limit' level"?

@dynamic I think it was mentioned that it's the Community Working Group (CWG) that normally determines which instances are limited or suspended. So (assuming that's the appropriate body), maybe put in something about how this does not restrict the CWG from taking other moderation actions if it finds them to be necessary?

@Brian Vaughan

We could add that. Is this suggestion a substitute for the edit I suggested, or in addition to?

@dynamic In addition to. I'm basically thinking it's more precise than saying "at least limit", and leaves follow up questions to normal processes.

@Brian Vaughan

I just read through the proposal guidelines and bylaws regarding governance, and I now want to check in about whether anyone has checked in with the working groups about these proposals.

Before proceeding, explore the operations docs to see if there is a working group relevant to your idea. If there is, be sure to contact them to discuss it. Perhaps it is something they can implement on their own, without a further proposal. But even if you do proceed, make sure you've at least consulted with the relevant working group.

I'm... really hazy about the process here.

@dynamic It looks like the CWG is the right group, and I did see someone mention that the CWG members were waiting to see how the vote played out, and from the members in the minutes, I know several of them have participated in this discussion. It seems like now's the time to check in with them, as the CWG, so I'm tagging @flancian @edumerco @mattnoyes

@Brian Vaughan I wonder if the proposal could say defederate (either suspend or limit) and leave the decision of which to do to the CWG?

@Brian Vaughan The current members of the CWG Ops Team are: @Flancian @Sam Whited @emi do and me. I think this proposal doesn't have to go to the CWG first, especially since there has already been a lot of discussion. IMO it is also better not to leave it to the CWG Ops Team to decide whether to suspend or limit Threads. Maybe other folks on the ops team have a different take?

@Matt Noyes

I agree that it should not be up to CWG to decide the moderation level for Threads.net.

@Dynamic I personally think the vote should be to suspend and not limit Threads. It will prevent data from social.coop from flowing to Meta via ActivityPub.

@Ed Summers, I strongly support full defederation from Threads.net, but I think that we are much more likely to achieve consensus on Limiting them, and that it would be extremely unfortunate if we keep dithering on which of these to do and end up taking no action at all.

Defederation can (and IMO should) be a separate proposal. I tried to make this very clear in the language of the proposal, but please let me know if there's anything that would make this clearer.