Threads & The Fediverse

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, i.e., anything else that speaks ActivityPub. 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:

  1. 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.

  2. 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.

Furthermore, the implementation of ActivityPub does not necessarily signify a willingness to federate with what we call the Fediverse, even if it were legally feasible to do so.

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 ActivityPub "standard", 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."

You should also read:

Toward a Paid Fediverse: The Future Beckons

As a systems architect, I am compelled to always consider two things among many: system capacity and costs. This translates into two questions: "how does it scale in capacity?" and "how much does it cost, and who pays?" These are two questions that few are asking when they place their trust in federated systems like the Fediverse. Let me be clear, I find it amusing and it's a place where I enjoy being. But this does NOT mean that I truly believe everything will be that way one day.

What's wrong with Italian Fediverse?

Today, while reading the news from the fediverse, I came across the remnants of an old discussion, which, due to the decision of some attention-seeking individuals, is being repeatedly brought up in an unnecessary and endless controversy. This serves as evidence that the Italian-speaking fediverse has a significant problem.

Threads e il Fediverso.

C'e' una certa eccitazione nel Fediverso (o "Mastodon" per i cefalopodi) per via della notizia che "Threads" abbia un'interfaccia ActivityPub, ovvero sarebbe capace di federarsi con il Fediverso, cioe' con qualsiasi altra cosa parli ActivityPub. Ci sono gia' le petizioni dei sysadmin , che rifiutano a priori di federarsi. E che a mio avviso sono tempo perso.

Fediverse, (about) the design.

I've reiterated several times on the point that ActivityPub is a terrible protocol (which is easy to agree), what I didn't mentioned so far is how bad is the implementation of most used instances. Under the architect point of view, it looks to me like developers are trying to write a "single user instance (which is - therefore - not supposed to scale) while actually it will be abused, up to thousands of users"