Meta Threads

Meta Threads (MT) refers to the ActivityPub app Threads released by Meta Platforms, Inc. (formerly Facebook, Inc.) in July 2023.

I had already decided, as of May or June, not to federate with MT for several reasons. We are, however, not taking any action against other instances who do choose to federate; this is a complex issue with room for legitimate disagreement, and I think it's important to encourage conversation in the independent fediverse around these topics.

Why are we blocking them?

Overall, it's a bit like the Nazi bar analogy

Roadblocking Corporate Takeover

Google EEEd RSS feeds

The largest of these reasons was a desire to put every obstacle in the path of corporate dominance and control of the fediverse ("fedi") and/or the open ActivityPub standard.

Corporate dominance and control over open standards and platform-genres has historically been carried out in the following ways (that I know of):

• Embrace, extend, and extinguish (EEE): enthusiastically support the protocol at first; then, offer your own supplementary standards which expand the capabilities of that protocol and, although technically "open", are difficult/expensive to implement; then get the majority of users captured by your implementations which depend on these new standards that you control, leaving the original standard meaningless.
• To drain the lifeblood from independent hosts and development of the genuinely-open standard and implementations thereof.

Too Much Damn Power

It should also be noted that even if Threads turns out to be a completely benevolent entity (there are already issues with it, so this seems unlikely), the simple fact of a platform being under effective central control is its own problem. It's already a problem for Mastodon (even being open-source and full-federated as it is) that the overwhelming bulk of contributed development money goes directly to Gargron rather than to a more accountable body; having the whole thing centrally owned and controlled is that same problem but larger by orders of magnitude. Development for any large software project should be funded by donations to an independent body, not by funds sent directly to a single person.

Likewise, the problem of mastodon.social existing as the "flagship instance" and the default place for most signups existed long before MT. (Many newer users don't even realize that mastodon.social is not the same thing as Mastodon.)

I could make an "elephant in the room" joke, but more accurately I'd compare it to inviting a supertanker into a small lake: there's not going to be a lot of water left for anyone else. Remember how Google+ drained the lifeblood from Diaspora, attracted a thriving and vibrant community that I enjoyed greatly, and then was quietly killed as a "failure" by arbitrary fiat of a single executive? (more: EEE)

Yes, fedi can survive MT coming and going, but only if we resist the temptation to adopt any "innovations" they may bring to the table without first verifying that they do not create a suppressive effect on independent instances and development... and right now I have no confidence that Gargron even sees this as an issue.

We need to be moving the other direction.

Terms under which I'd reconsider

• Meta must fund a self-governed cooperative to manage development of the ActivityPub standard and implementation of it.
  • Funding should be sufficient for, say, five years of five full-time developers. Let's say 100k/year for each developer, x5 devs x5 years = $2.5M. This would be a trivial amount to them, I should think, given how much they must have invested in Threads.
  • The cooperative itself could decide how to actually spend this, but that would be enough to really focus on keeping the standard from being co-opted.
  • Funding should be maintained at that level indefinitely, i.e. there should always be $2.5M in the coffers at the beginning of the fiscal year, so that Meta can't meaningfully exercise financial pressure by threatening to pull out if things don't go the way they want.
• Meta must agree to full transparency over the data they collect and retain from each instance.
• The Threads app must be open-source.

If we are going to be able to defend ourselves against possible abuses from the 5000000-ton gorilla that is Meta, they need to share enough of their power to make coexistence possible and help level the playing field just a little. Only this way can they prove that their intentions are truly benevolent. (They won't, because they aren't. This is me being reasonable and offering them a choice.)

It's not going to happen, but that's what is needed.

(The same conditions should probably also apply to BlueSky; I'll eventually do a page about that when I have more information. -W.)

Notes

Not sure which of these are actually Facebook accounts:

• 2019-02-24: twitter.activitypub.actor/facebook
• 2021-08-13: birdsite.slashdev.space/users/fb_engineering
• 2021-10-29: birdsite.slashdev.space/users/facebookapp