Federating to Meta Threads

(auto-translated Text)

In July 2023, it was announced that Meta’s Twitter/X competitor “Threads” would probably also set foot in the so-called Fediverse - the network that connects various social platforms such as Mastodon, MissKey, Pleroma, KBin and Lemmy. This would make it possible for Meta’s own users to interact with users and content from the Fediverse - and vice versa.

This announcement caused panic in the Fediverse at the time. While some saw this as a success (after all, this was a significant step towards service interoperability!), others were concerned and even alarmed. After all, Meta could have nothing good in mind with this step and, according to an EEE strategy, only wanted to wipe out the Fediverse or win over and retain its users.

After a wave of panic and outrage, not much has happened since then. The first instances have blocked threads.net preventively; others - such as metalhead.club - have done nothing for the time being. On the Metas side, there has been no news worth mentioning regarding ActivityPub or Fediverse support.

Last week, however, the issue came to a head again when Mastodon lead developer Eugen Rochko announced that a limited ActivityPub connection between selected Threads.net profiles and the Fediverse is now being tested. For example, mosseri@threads.net could now be followed. Subscriptions in the other direction were not yet possible. The heated discussions from July were warmed up again:

Was it problematic to allow a corporation like Meta to participate in the Fediverse? Or was it a step into the future that many had so much hoped for? To this day, there are still heated discussions and deliberations - unfortunately often based on dubious information. Although Threads has not yet arrived fully in the Fediverse, opinions could not be more controversial. In this post, I - the admin of metalhead.club - want to explain my position and my strategy for dealing with Threads.

First of all, I want to agree with all the critics who point to Meta’s past and accuse the company of handling user data unscrupulously and behaving in a selfish and greedy manner rather than in a way that promotes society. Meta is a public limited company that is driven by only one thing: Desire for economic profit. As a public limited company, the group is even obligated to act in such a way that profitability is the top priority. Otherwise Meta would be of no interest to investors. One can now ask what Meta expects from joining the Fediverse, which is more of a non-profit organization. There are various theories. It is possible that Meta wants to capture some of the renegade ex-Twitter users. Or perhaps the Fediverse is seen as a dangerous development that the aforementioned EEE strategy is intended to put a stop to. Or perhaps it is a clever move to allow interoperability to a certain extent in order to take the wind out of the sails of regulatory bodies - such as the EU - and avoid coercive measures. We do not know. But it should be clear to many: However, the decision at Meta was certainly not made out of fun, a “hacker spirit”, altruism or an idealistic motive.

So we are dealing with a complicated situation: For years, people have wished for an internet that tears down walls and (technically speaking) talks to each other. Now there is a small glimmer of hope, but the new potential participant has a dubious reputation and we don’t really know its honest motives.

Generally speaking, I’m in favor of companies supporting the ActivityPub-based part of the Fediverse by providing compatibility in their products. Just like Automattic (Wordpress) or Flipboard, for example, are already doing. But how do you deal with a company that has such a bad reputation, especially among users of the Fediverse?

Moderation 🔗

Let’s forget for a moment that Threads is a meta-product. How would we assess the situation if a new Mastodon instance connects to ours and wants to exchange data? As a rule, no manual activation is required. The new instance can communicate with us and the users can exchange data with each other. This happens hundreds to thousands of times a year - depending on the size of the instance. If a user of the connected neighboring instance misbehaves, their posts are hidden or deleted - or the user is blocked completely. Their posts can then no longer be received on metalhead.club. If the undesirable behavior spreads to other users of the instance or if the moderators of the other instance refuse to take action, an instance can also be completely blocked or its reach restricted.

This scheme can easily be applied to Threads as well. Of course, we can make assumptions about the quality of content shared on Meta, but let’s just wait and see if our guess is correct. If Threads is a problem in terms of moderation, we’ll deal with it in the same way as with all other instances with which metalhead.club interacts. The number of advertisers, turnover or number of users are not criteria that I use to allow or restrict the exchange of data with other instances. Anyone who dumps sewage on the Internet has to live with the fact that I want to keep my systems clean and block them.

Privacy and data protection 🔗

… the main reason why some users are so panicked. Unfortunately, there is a lot of half-knowledge, some myths and recommendations that fall short. I will try to bring some order into this.

First, let’s be clear about what data Meta can get from us other Fediverse users - and then consider whether this is really as beneficial to Meta as some assume. We need to distinguish between data that is exchanged as a result of federation (i.e. data exchange between Fediverse servers) and data that is made available via other channels (primarily the web interface / the instance’s website).

A federation data exchange between a Mastodon instance such as metalhead.club and Threads would take place via the ActivityPub protocol. A kind of common language in which two servers (or instances) can communicate. The language defines what kind of information can be exchanged. The servers make requests to each other or send information to the other server without being asked if they know that the other server is interested.

A server that receives a request for specific information always has the option of leaving the request unanswered. It only responds to requests that it considers legitimate. I mention this because it is by no means the case that Threads has the ability to access all user data when participating in Fediverse. Threads only gets what metalhead.club offers them. What information is offered depends on the interaction, but this can be, for example:

• Profile name and avatar
• A public post
• A private message to a @thread.net user

This is all data in which Threads has a legitimate interest. Some of it is public data - but some of it is also data that a threads.net server needs to know in order to deliver it to its users. A private direct message, for example. So if a metalhead.club user interacts with a Threads user, the latter must expect Meta to process, use or analyze the underlying information. That should be clear so far. But what about other information?

• E-mail address to which someone has linked their metalhead.club account
• Non-public posts to followers on other instances
• Private notes in other profiles
• Lists
• Followed hashtags
• Followed users (if not public)
• Date of registration
• Blocked users
• Filtered hashtags
• …

This type of data remains on the instance or, in the case of posts or direct messages, is only transmitted to instances that must have this information because they are the target of the information.

Meta therefore does not have the comprehensive monitoring and analysis options that some people fantasize about. If Meta gets data from metalhead.club, it is only because:

• A thread user is the explicit target of the data and it has been implicitly or explicitly specified as such by the user themselves … or …
• The information is per se public for Threads and other interested parties

Threads cannot make arbitrary use of information. Through our settings, our usage behavior and the choice of Fediverse software (Mastodon) we ourselves determine which information we disclose and which we do not.

If you do not want your data to fall into the hands of Meta, you must therefore make every effort not to fulfill the two requirements mentioned above, i.e:

• Do not publicly disclose any information that should not be public (this applies in particular to profile names, avatar, bio/profile description, public posts, follow/followed lists, …)
• Do not interact with @threads.net users - recognizable by the username of the other user

In the case of Mastodon, however, there is also a pitfall that needs to be considered: The “followers only” post scope. Anyone who does not share a post “publicly”, but “for followers only”, should be aware that the setting by default by no means ensures that you have full control over its distribution. Although the boost function is deactivated and the post is not displayed in the web interface without logging in, the setting is not really private either. Because by default, anyone who is not blocked can become a follower with one click and without active consent and thus bring themselves into the circle of recipients.

So if you write a post to “Followers only” and a Threads user follows you, the post will also be sent to Threads/Meta. This can be prevented by two measures:

• Option a): Block the instance “threads.net” via the settings (open any profile of a Threads user => select “Block domain treads.net” there)
• Option b): Activate mandatory follow-approvals. In the settings: “Public Profile” > “Privacy and Reach” > deactivate “Automatically accept new followers”. From now on, new followers must be confirmed individually before they can be followers. Threads users can therefore be rejected.

The user therefore has the choice of who their data reaches - the profile just needs to be configured appropriately and user behavior adapted accordingly.

It sounds a bit trite, but: Whoever posts publicly, posts publicly. Be aware of this. Your post could be printed in the newspaper the next day, your ex-partner could read it, your disagreeable neighbor, your bosses, Mark Zuckerberg himself - and anyone who wants to can download the content, save it forever or process it further. Even if it is unpleasant or forbidden - you not only have to live with the fact that other users will use your public data inappropriately and not as intended - you have to reckon with it. Just as someone could look at my public photos on Mastodon lustfully, Meta could analyze my posts and see what interests I’m pursuing. I probably didn’t consent to this the second it was posted, but it’s out of my control what happens to the data.

This is not intended as a call not to post publicly. A public exchange can be very useful and profitable. I want to continue to encourage you to give your posts reach and enable a public discussion…

… However, those who have concerns about sharing data with Threads/Meta should perhaps be more aware that

1. They already have all means to address information in a targeted manner and thus limit the circle of confidants
2. Meta is by no means the only party that makes or could make use of public data.

Making life difficult for Threads 🔗

This brings us to a piece of misinformation that has been making the rounds in recent days. Anyone who has understood that you either have to deliberately pass the data to Meta or voluntarily share it publicly in order for it to reach Threads may still be of the opinion that you should make life difficult for a company like Meta. Consequently, Threads should also be blocked from the public posts of some users.

Some articles recommend blocking the threads.net instance in various ways. In many cases, however, this step is unlikely to have the desired effect, because without the Mastodon admin’s intervention, the step only means that you can no longer be harassed or contacted by threads.net users. The contents of Threads are hidden. The problem is that this does not prevent Threads from continuing to retrieve public posts. This is easily possible because another server does not have to identify itself to retrieve a public post. Retrieval is usually anonymous. Unlike with private posts, Mastodon cannot prevent public posts from being retrieved because it is not clear who is retrieving them.

This loophole can be plugged by activating a function called “Authorized Fetch” on the instance. This ensures that public data can only be retrieved if the requesting server (e.g. Threads) has revealed its identity. Access could be denied at this point.

However, an “Authorized Fetch” is not active by default in Mastodon and other ActivityPub-based software. Accordingly, access to public data cannot be controlled and blocking is pointless in this case. Incidentally, the setting can be activated in the admin interface under “Administration” > “Server settings” > “Require authentication from federated servers”. However, the setting has some disadvantages in terms of performance and quality of the federation and should only be activated with caution:

“[…] However, this comes at the cost of a performance penalty, reduces the reach of your replies, and may introduce compatibility issues with some federated services. In addition, this will not prevent dedicated actors from fetching your public posts and accounts.” - Mastodon Admin Interface

You can find more about “Authorized Fetch” here: https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

Anyone who now thinks that their posts are safe from access by Threads is mistaken: With an “Authorized Fetch” we have only restricted ActivityPub-based access by Threads to public posts. Nothing and nobody prevents Threads or any other actor from accessing the web interface of a Mastodon instance and downloading the data from there.

Does this make it more inconvenient for Threads to get the data? Yes, possibly a little. But the hurdle is small and insignificant for a company like Meta. If public posts were actually of value to Meta (for machine learning, for example), they could simply be obtained by scraping the web interface. A little more complicated, but in the end even a more sensible solution, because you can collect much more text beyond the Fediverse than via an ActivityPub interface.

The usefulness of the “Authorized Fetch” function in combination with blocking at user level is therefore highly doubtful. Nevertheless, I have decided to activate it on metalhead.club on a test basis to see whether it brings us added value in terms of user satisfaction or whether the price in terms of federation problems, performance or compatibility is too high.

Concluding Words 🔗

The Fediverse is in turmoil. On the one hand, this is understandable, because a powerful player who has rarely attracted positive attention wants to get involved. A skeptical attitude is more than appropriate. Nevertheless, I would urge you not to fall into senseless activism that, in the worst case, lacks any logic. There is already hostility between admins and among users because individuals are trying to find out who the “good guys” in the Fediverse are - and who is allegedly making common cause with Meta. It’s taking on grotesque proportions at times and as an admin I don’t want to be influenced by propaganda from one side or the other. What counts for me is the vision. I would like to see an Internet that is more decentralized through shared protocols and technologies. AcvitvityPub has the potential. It works wonderfully on a small scale. Perhaps we will see whether it also works on a larger scale.

If it goes well - great. If it goes wrong, nobody will take AcvivityPub away from us. Microsoft may have successfully implemented its EEE strategy in the business environment. But does any freedom-loving Mastodon user actually use Outlook privately against their will? Probably not. Because e-mail (even if it is tied up by Microsoft to some extent and used in a mutilated way) still exists in its “pure” form. Those who are passionate Mastodon users will not switch to Threads if there is an ActivityPub fork of Threads in the future. The Fediverse may return to its current, simple form in the event of disaster. Maybe without basketball world stars. But we don’t have them in the Fediverse even now … ;-)

In a nutshell: What is metalhead.club doing? 🔗

Not much. As the founder of the instance, I don’t see much need for action at the moment. I will / we will:

• Enable Authorized Fetch: to give users something like a small handgun. Not really serious because of the technical limitations, but a bit effective and the user has a bit more power over their public posts. However, we have to observe whether there are technical difficulties. If the price is too high, we will have to reverse the setting and appeal to users’ common sense to only share publicly what Meta, Microsoft, Google and co are allowed to know.
• keep an eye on Threads: My moderation team and I will keep an eye on developments. If we see that Threads’ involvement is significantly harming our instance or the development of the Fediverse, we will sever ties.
• Do not give Threads a special treatment: We treat Threads like any other instance. We do not guarantee federation - just as we do with other instances. Anyone who dumps sewage on us will get the bill.

I understand that some people are very worried, but I promise that the panic is exaggerated. We should keep a cool head and be open to new things. The killswitch is always firmly in our hands and hopefully we won’t need it.

The Fediverse is an experiment. Let’s treat it like one.

FAQ 🔗

“I don’t want to see content from Threads users - What can I do?” 🔗

You can hide or block individual Threads users or all Threads users. To do this, visit the profile of any Threads user, e.g. mosseri@threads.net. Click on “Block domain threads.net” in the profile menu. Threads users will no longer be able to contact you and you will no longer be shown any content from threads.net.

Please note: Threads users can still view your public posts if they wish to do so.

“I don’t want to transfer data to threads.net - what can I do?” 🔗

Be careful not to post any information publicly that you do not want to transmit to Threads. In principle, public information is always visible to Threads - even if we make access to it more difficult.

To be on the safe side, you can configure your profile in the settings so that you first have to accept new followers (Settings > Public Profile > Privacy and Reach > Deactivate “Automatically accept new followers”). You can then share content “only with followers”. This means that data is only distributed to the servers of your accepted (non-Threads) followers.

“I’ve heard about Authorized Fetch - has metalhead.club activated this?” 🔗

Yes, we are testing the use of “Authorized Fetch”. This allows us to control access to public content to a certain extent and every user can block threads from accessing their posts on their own initiative using the “Block domain” function. No more posts are then sent to Threads via Federation / ActivityPub - even if a post is shared publicly.

Please note, however, that it will still be possible to read your public posts via the web interface - this also applies to Threads. We do not know whether Threads will make use of this option. So don’t rely on this and don’t share any content publicly that you want to protect from being analyzed by Meta.