Skip to content

The free fediverses should focus on consent (including consent-based federation), privacy, and safety

Part 2 of Strategies for the free fediverses

A highway sign, in the shape of an arrow, with the word Consent.

Part 2 of Strategies for the free fediverses.  As the first post in the series discusses, the "free fediverses" are regions of the fediverse that reject Meta and surveillance capitalism, and these strategies position the free fediverses as an alternative to Threads and "Meta's fediverses".  That said, this and most other strategies in the series are also useful for regions of the fediverse (and software) that doesn't reject Meta.  

"People on the Fediverse chose not to federate with gab or truthsocial. They and their admins chose to exercise their freedom of association to not federate with those networks."

– Esther Payne, in Consent and the fediverse

As Anil Dash has pointed out, consent is a key (often-unstated value) in the fediverse. The firestorm over the summer over an early opt-out version of Mastodon's new search functionality is a good example of how passionately people care; it was strong enough that Mastodon's BDFL (Benevolent Dictator for Life) Eugen Rochko reconsidered his original support for the non-consensual implementation, which then evolved to an opt-in consensual approach.

Meta, by contrast, has thrived by exploiting data gathered without consent. So this is a great opportunity for the free fediverses to highlight the contrast with Threads. Meta's horrible track record on privacy, and their unwillingness to act against harassment, hate speech, and hate groups, create other great opportunities for the free fediverses.

That said, the free fediverses will need to do some work to capitalize on this opportunity. Mastodon and today’s fediverse are unsafe by design and unsafe by default, there's very little privacy on most of today's fediverse, and the commitment to consent is intermittent. As Erin Kissane points out in Untangling Threads, many people see a consent-based allow-list approach to federation as less "open" – a good example of Christina Dunbar-Harris's point in Hacking Diversity that the "interpretations and norms of openness on which open source rests" often run counter to the goal of providing more safety. When Instagram CEO Adam Mosseri announced Threads' plans to make federation opt-in (consent-based) for individual users, Rochko immediately criticized the decision to provide more privacy and safety to Threads users.  How sad is it that (at least in this case) Instagram's CEO appears to understand consent better than the CEO of Mastodon gGmbH?

Mastodon is particularly egregious on this front.  Its documentation, for example, describes consent-based allow-list federation as "contrary to Mastodon’s mission." Mastodon also approves follower requests by default without asking for consent. Hmm. Even if you're not an expert on online privacy and safety, which sounds better to your: "Nazis and terfs can't communicate with me unless I give my permission" or "Nazis and terms can harass me and see my followers-only posts until I realize it's happening and say no"? Unsurprisingly, Mastodon's BDFL Rochko is a strong supporter of federating with Meta, and so are most of the other "bigger is better" folks who don't like the idea of consent.

The good news is that many fediverse platforms already support consent-based approaches to federation. PeerTube, for example, has an option for manual approval of federation requests; so does Pixelfed, along with triggers and custom rules which allow for partial automation. Akkoma, GoToSocial, and even Mastodon (despite its philosophical objections) all support "allow-list" federation.6 PixelFed recently added the ability to make federation with Threads opt-in for individual users.

There aren't yet a lot of good tools to make consent-based federation convenient scalable, but that's starting to change. Instance catalogs like The Bad Space and Fediseer, and emerging projects like the FIRES recommendation system. FSEP's design for  an"approve followers" tool, could also easily be adapted for approving federation requests. ActivityPub spec co-author Erin Shepherd's suggestion of "letters of introduction" could also work well at the federation level, and the "fedifams" and carcoles I discuss in The free fediverses should support concentric federations of instances could help with scalability.  So while things might be a big awkward in the short term, this too shall pass.

Adding individual opt-in federation consent to existing software should be fairly straightforward. In fact, most fediverse platforms other than the mainline Mastodon code base already have the concept of local-only posts that don't federate – and the Glitch and Hometown Mastodon forks (variants) have had this functionality since 2017, it's just that Rochko has blocked this functionality from the main code base.  

And there are lots of other ways for the free fediverses to improve privacy and safety, some straightforward, others more complex. Changing the default to require approval for new followers is a one-line code change in Mastodon; adding functionality like FSEP sketches to provide more information to make a better decision about whether or not to approve is more work.  

On the privacy side, threat modeling Meta, the fediverse, and privacy (still a draft) goes into detail and includes a series of recommendations for developers and fediverse software projects for instance admins, fediverse developers and software projects, businesses, government agencies, civil society organizations, and funders. Improving privacy and safety in fediverse software is a concrete suggestion for a social threat modeling approach as the next step.

Stay tuned for more!

The next installments in Strategies for the free fediverses will discuss the "networked communities" aspect of the fediverse (one of its current strengths), and the idea of concentric federations of instances (which leverage that strength while also addressing the challenge of scaling consent-based federation). And there's a long way to go after that!

To see new installments as they're published, follow @thenexusofprivacy@infosec.exchange or subscribe to the Nexus of Privacy newsletter.

Image credit

Consent by Nick Youngson CC BY-SA 3.0 Alpha Stock Images, via Picpedia.org

To see new installments as they're published, follow @thenexusofprivacy@infosec.exchange or subscribe to the Nexus of Privacy newsletter.