Difference between revisions of "Meta Threads"
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Meta Threads]] (MT) refers to the ActivityPub app {{l/wp|Threads (app)|Threads}} released by Meta (formerly Facebook, Inc.) in July 2023. | + | [[Meta Threads]] (MT) refers to the ActivityPub app {{l/wp|Threads (app)|Threads}} released by {{l/wp|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. | + | I had already decided, as of May or June, not to federate with MT<ref name=preblock /> 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?== | ==Why are we blocking them?== | ||
Overall, it's a bit like the {{l/wikt|Nazi bar}} analogy<ref name=nazibar /> | Overall, it's a bit like the {{l/wikt|Nazi bar}} analogy<ref name=nazibar /> | ||
===Roadblocking Corporate Takeover=== | ===Roadblocking Corporate Takeover=== | ||
| + | [[File:Shuttering google reader.334841466545c250.jpeg|thumb|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. | 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. | ||
| Line 12: | Line 13: | ||
* To drain the lifeblood from independent hosts and development of the genuinely-open standard and implementations thereof. | * To drain the lifeblood from independent hosts and development of the genuinely-open standard and implementations thereof. | ||
===Too Much Damn Power=== | ===Too Much Damn Power=== | ||
| − | It should also be noted that even if Threads turns out to be a completely benevolent entity (there are already {{l/sub|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 that the overwhelming bulk of contributed development money goes directly to Gargron rather than to a more accountable body. Development for any large software project should be funded by donations to an independent body, not by funds sent directly to a single person. | + | It should also be noted that even if Threads turns out to be a completely benevolent entity (there are already '''{{l/sub|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 that the overwhelming bulk of contributed development money goes directly to Gargron rather than to a more accountable body. 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.) | 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? | + | 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. | 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. | We need to be moving the other direction. | ||
| + | |||
==Terms under which I'd reconsider== | ==Terms under which I'd reconsider== | ||
* Meta must fund a self-governed cooperative to manage development of the ActivityPub standard and implementation of it. | * Meta must fund a self-governed cooperative to manage development of the ActivityPub standard and implementation of it. | ||
| Line 27: | Line 29: | ||
** 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. | ** 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. | * 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.) | 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. | 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== | ==Notes== | ||
Not sure which of these are actually Facebook accounts: | Not sure which of these are actually Facebook accounts: | ||
| Line 38: | Line 42: | ||
==Footnote== | ==Footnote== | ||
<references> | <references> | ||
| + | <ref name=preblock>We also pre-emptively blocked a set of domains believed to be owned by Meta.</ref> | ||
<ref name=nazibar> | <ref name=nazibar> | ||
* '''2023-04-24''' [https://kcraybould.substack.com/p/substack-notes-and-the-nazi-bar-problem Substack Notes and the Nazi Bar Problem] | * '''2023-04-24''' [https://kcraybould.substack.com/p/substack-notes-and-the-nazi-bar-problem Substack Notes and the Nazi Bar Problem] | ||
* '''2022-04-09''' [https://www.boredpanda.com/bar-bartender-nazi-punk-iamragesparkle/ Bartender Savagely Kicks A Polite Nazi Customer Out Of His Bar And Explains Why It’s Important To Do So]</ref> | * '''2022-04-09''' [https://www.boredpanda.com/bar-bartender-nazi-punk-iamragesparkle/ Bartender Savagely Kicks A Polite Nazi Customer Out Of His Bar And Explains Why It’s Important To Do So]</ref> | ||
</references> | </references> | ||
Latest revision as of 21:14, 8 July 2023
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[1] 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[2]
Roadblocking Corporate Takeover
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 that the overwhelming bulk of contributed development money goes directly to Gargron rather than to a more accountable body. 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