Threads & The Fedeverse
There is a certain buzz in the Fediverse (or “Mastodon” for cephalopods) due to the news that “Threads” has an ActivityPub interface, making it capable of federating with the Fediverse, ie, anything else that ActivityPub speaks. There are already petitions from sysadmins who categorically refuse to federate, which, in my opinion, is a waste of time.
There are numerous reasons why I say this.
The primary reason is that the ActivityPub interface exists because of a European directive that mandates social platforms, which are limited to small text messages, to be interoperable. Thus, this interface is not necessarily designed specifically for Threads to federate seamlessly with any instance in the Fediverse.
Certainly, it can be achieved if Threads wishes to do so, but let's be clear: why SHOULD Meta do it?
Personally, I see this move as having only “cons” and no “pros.” The mere existence of this interface suggests that, theoretically, it could be done, but when I delve into the obligations involved in federating with the Fediverse, it becomes evident that they have no intention of doing so.
But let's take it one step at a time and consider some technical aspects.
ActivityPub is essentially a dictionary, with some conventions that are more connected to practices rather than strict standards. On the same dictionary, one can construct entirely different actions and entities.
This means, for instance, that there hasn't been an actor designated for Groups yet. Some software has chosen to implement one, but major platforms like Mastodon, Pleroma, and others have never embraced it, which means they don't see the Groups of Lemmy and Kbin as such.
Thus, on a technological level, it is by no means guaranteed that Threads using ActivityPub would enable seamless federation with Mastodon or vice versa.
Indeed, it is possible, if not probable, that Threads uses a dialect of ActivityPub that is entirely incapable of federating with Mastodon, Pleroma, Misskey & co, but is perfectly capable of federating with other OTT (Over-The-Top) platforms, such as Google, YouTube, and others.
This would allow Threads to both federate with other GAFAM (Google, Apple, Facebook, Amazon, Microsoft) entities, thereby complying with EU regulations, and keep the Fediverse out, which would then be perceived as “those who use the ActivityPub dialect incorrectly. ” Even if the Fediverse were to complain that it's not the “true” ActivityPub, it would appear to most as seeing someone entering a highway and complaining that everyone is in the wrong lane.
Hence, first and foremost, ActivityPub does not necessarily equate to federation, and personally, I find it rather unlikely. Even WhatsApp uses a dialect of XMPP, but it is not compatible with the rest of the XMPP world.
Assuming that Meta has decided to allow federation using the most commonly used ActivityPub dialects in the Fediverse, there are several obstacles to this decision.
First and foremost, if they were to choose to federate, they would need to address several issues:
- Compliance with the Fediverse reporting mechanism: This entails moderating all external instances to prevent them from sending inappropriate or spam content into Threads. In such a scenario, malicious actors could exploit ActivityPub to disseminate Fake News, spam, and other unwanted materials within Threads.
- Compliance with GDPR: If a Threads user sends a message to a user on a Fediverse instance, for instance, Meta would be transferring data to a third party whose exact location might not be definitively identifiable. It could be an instance running on a Raspberry Pi in a private residence.
The first matter, naturally, entails substantial costs. An actor could send messages to /inbox from any IP address and domain, provided they use one of the numerous available ActivityPub libraries. While a proficient team of administrators could manage the situation, it would likely be more expedient to adopt an approach akin to: “Do you want to federate? Get identified, get credentials, and perhaps pay for the privilege.”
Furthermore, it is crucial to underscore that even if Meta were to decide to federate, it might not ensure seamless interoperability with all instances within the Fediverse. Disparate dialects, customizations, and different implementations could still give rise to compatibility issues. Consequently, the decision to federate should be thoughtfully considered and accompanied by measures to address both technical and legal obstacles.
Therefore, by default, Threads would not federate, even though it has the capability, and it would wait to establish a (commercial) contract with someone to set up federation.
The second aspect is genuinely complex because you do not know who is following the users and, from that point on, acquiring a copy of the public traffic of those users themselves. In this regard, the issue with GDPR is that you are providing data to an unknown data processor.
If we are talking about small instances in the Fediverse with a small number of users, which fall outside the scope of GDPR surveillance, it probably wouldn't be a significant problem. However, if Threads were to gain access to Twitter-like number of users, the system would be unable to federate with the “Fediverse” while simultaneously complying with GDPR regulations.
Therefore, I do not endorse this atmosphere of conflict or overexcitement:
First, he mere utilization of ActivityPub does not guarantee the capability to federate with what we refer to as the Fediverse, primarily due to the ambiguity inherent in the standard.
Personally, I believe that they have incorporated ActivityPub to federate with other prominent actors, employing their own version of ActivityPub, which remains within the realm of “standard” ActivityPub, which exhibits a considerable lack of structure. Consequently, one can conceive numerous protocols using ActivityPub that do not foster federation, yet they all still fall under the umbrella of “ActivityPub.”
In general, I would advocate for a stance of “Calm and Behave.”