Meta can rage farm Mastodon without controlling it
Meta can introduce their signature rage farming to the Fediverse. They don't need to control Mastodon. All they have to do is introduce it in their app. Show every Threads user algorithmically filtered content from the Fediverse precisely tailored for maximum rage. When the rage inducing content came from Mastodon, the enraged Thread users will flood that Mastodon threads with the familiar rage-filled Facebook comment section vomit. This in turn will enrage Mastodon users, driving them to engage, at least in the short to mid term. All the while Meta sells ads in-between posts. And that's how they rage farm the Fediverse without EEE-ing the technology. Meta can effectively EEE the userbase. The last E is something Meta may not intend but would likely happen. It consists of a subset of the Fediverse users leaving the network or segregating themselves in a small vomit-free bubble.
Some people asked what EEE is:
So many knee-jerk reactions.
This is an open protocol with complete freedom to create apps and scripts. If this becomes an issue users could block certain interactions in a granular manner, for example block replies from certain instances.
XMPP being thrown around as an example makes me think people who do it weren't there to witness it. XMPP by itself wasn't really used by many but there were also many more popular messaging platforms at the time. XMPP wasn't killed because it wasn't ever alive other than short golden era when it was mostly a way to open itself to third party clients (Gaim, Trillian, Adium etc) which was very nice.
Next year EU is going to make all tech giants open in this way again. Mastodon can EEE Threads too by being a better implementation. It has no commercial pressure and Activity Pub and formatting tweets is not as complex as a web browser engine or a word processor document format which are way better examples of successful EEE.
If you defederate you'll end up exactly where XMPP is.
I agree with the sentiment, I'm not a fan of preemptively blocking meta on instance level, especially when everyone was touting about how the fediverse is corporation resistant and by design it is resilient because of it's horizontal nature, but at the first sign of threat they resort to the nuclear option.
Having said that, Lemmy specifically lacks tools on the user level, especially blocking instances. If a user doesn't want to associate at all that is understandable (privacy concerns, not wanting to interact with hate groups, etc) but right now they can only block communities and users individually, which would make it impossible to block meta.
Lastly, I feel there are avenues that haven't been properly explored, like forcing them to open source if they want to federate. (On the grounds of privacy concerns and security) In practice that would be the same as blocking them, but it would laid out a good foundation for new companies that want to enter the space without having to discriminate on a case by case basis.
Problem is that blocking is the nuclear option and everyone blovking before something comes out, which no one knows the danger yet like a hate speach platform would entail, goes against the spirit of the fediverse.
My reason for preemptively blocking Threads is much simpler - Lemmy exposes a TON of data from all instances. I simply don't want to feed the data hog any more than absolutely necessary.
But a counter is that much of that information is already public and can be scraped, they aren't gaining much on outside meta users that they aren't already able to do.
Best advice at the end of the day is that for social media, unless advertised on privacy, never post anything you dont want to be public. And for cases like lemmy, expect even metadata to be available for anyone interested.
I understand the wish to not interact with meta, even if its for privacy concerns.
But Im a firm believer that it is the user first who needs to make that decision, not the instance. But as I said, Lemmy being the only one of the big fedi platforms right now that doesnt have a feature for instance/domain blocking user level kinds of screws this up.
There is no technical way for the user to make this decision as data gets federated across instance databases, not users' browsers. I do run my own, which is what enables me to make this decision, and anyone agreeing with it is welcome to come along.
When you say that there is no technical way, you sre referring to users not being able to block instances right?
If it's that I don't think it is that difficult to implement, Mastodon already allows for that. And also the app "connect for lemmy" in its last update has given the option to block instances user level, I don't really know yet if it blocks all users from that indtance from appearing or only communities as I haven't tested it yet.
Regardless to say, if we can get the appropriate tools this definitely could be a decision for users to take, if we make it so that they can completely block any and all content coming from a big instance.
A user blockin visibility of content is very different from that content not being federated.
I don't think Mastodon allows user blocking instance either but I don't see why that can not change in the future.
I'm not sure forcing open source on other instances is the right way to go. I imagine that in the future there could be instances that offer more polished experience, maybe a really nice proprietary app, that are commercially funded. As long as we have open alternatives and interoperability then we should be fine. In terms of privacy it's a matter of regulations.
I also fully respect choice of some instances to defederate from commercial platforms but in a rational environment it would be akin to subset of Linux users opting to use free software only with no binary blobs and things like that. Perfectly reasonable thing to do if that's what your ethics / philosophy dictates. Just don't think it's something that is a net benefit to average person.
Good points. I'm sure there are other potential solutions to reduce the fear of EEE taking place here. I don't really think EEE would work, since instances are supposed to be small and operate horizontally, it is kind of impossible to kill Lemmy as long as we understand that we need to spread out a little bit (otherwise huge instances being defederated hugely impacts the user experience)
One thing though, Mastodon does allow for blocking domains. I just tried it over Mastodon.online and also through the fedilabs app, both are working. Kbin also has that feature, wish they implemented it to Lemmy so that we can empower users to customize their experience without needing to self host.
Ok WTF does "EEE" mean? I've seen people throw it around as if it's some totally common abbreviation. Even if I google for it, all I find is some horse virus.
Embrace, extend, extinguish.
Embrace an open standard by using it yourself, start extending it at a pace competitors can't (preferably obfuscating how it works), leave everyone behind.
A good example is Microsoft Internet Explorer back in the day. Web technologies like HTML and CSS are open standards and at the time fairly straightforward. Once Microsoft hit critical mass by bundling IE with Windows they took leadership from Netscape and started adding more and more proprietary crap like ActiveX which some sites opted to use because everyone was using IE anyway and people using other browsers were forced to use IE. This was also a major issue for Linux users at the time.
It took years of regulatory / antitrust pressure, tremendous effort from Mozilla and their browsers, as well as big players like Google and Apple embracing KHTML (later forked into WebKit and then Blink engines) to unscrew humanity from that depressing era of internet history.
Web browsers working slightly differently is still an issue without anyone breaking compatibility on purpose. It was just so much worse when someone did it maliciously.
Can you expand on that?
https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en