Threads

I’ve received a lot of varying feedback on Instagram Threads, and the potential that it joins the Fediverse in the next few months. I’m also aware that there is an ongoing initiative among some instance admins to preemptively block Threads.net from federating with their server.

Instances are free to block whoever they choose, but at this time mstdn.party and mstdn.plus will not be suspending (defederating) Threads ourselves. (We may limit Threads depending on how their federation works, more on this below)

Our current policy is to limit and suspend servers based on whether their content violates our rules, not based on their owners. I also personally believe that defederation is a heavy-handed approach to moderation, and try to reserve it for content which is blatantly illegal or entirely in violation of our rules (i.e. the entire instance is in violation, and not just a handful of users on that instance). Most Threads users will be regular people posting regular things, so this would not apply.

The reason I’m comfortable with not defederating most fediverse servers—including Threads—is that Mastodon provides a plethora of self-moderation tools you can use to personally protect yourself and your privacy, up to and including full domain blocks you can implement yourself on a user level.

I don’t want Facebook to access my posts, or Threads users to follow me

You can individually block Threads.net yourself. This will prevent Threads users from following your account, and hide all posts from Threads users from your timeline.

This being said, Mastodon does not make it easy for you to block an instance which does not yet exist, although it is possible. When Threads federation actually launches, I will update this post with clearer instructions on how to do so.

If you are concerned about the privacy of your profile or posts, you may also wish to consider setting your profile to private to control which instances can follow you as a general rule.

I don’t want Facebook/Threads to access my personal information

Mastodon/ActivityPub is built with your privacy in mind. Your private information, such as your email, IP address, or password is never shared with other servers, including Threads. Your public posts will be accessible—unless you block Threads.net individually—in the same way that they are accessible to anyone on the internet, including search engines and logged-out users.

If you are concerned about big tech companies scraping your posts, you should have a locked account and post to followers only. It is impossible for us to protect the privacy of your posts if you are posting publicly, no matter who we federate or defederate with. Search engines, AI companies, and anyone else can easily scrape your posts in ways we have no control over when your posts are public.

I really think you should block Threads, everyone else is!

It’s great that smaller communities have the option to defederate with Threads, if that’s what their users want. Our Mastodon instances host a very large and diverse group of people with differing opinions, and generally expect us to not take a heavy-handed approach to blocking other instances.

In fact, allowing federation with Threads is likely a net privacy benefit for our users. I recognize the fact that many people will be interested in following content on Threads whether we block it or not. By following Threads users from a trusted Mastodon client and instance like mstdn.party or mstdn.plus, you avoid the need to install Facebook’s proprietary Threads client or register your personal information with Threads directly.

If you are not interested in following content on Threads, you have the freedom to block or view the content you’d like on our instances, and personally blocking Threads provides a nice middle-ground without restricting others. If you still disagree, you may be better off choosing another smaller Mastodon instance which will block more content on your behalf. Migrating your followers to another instance is always an easy option with Mastodon.

What if Threads is full of spam or other moderation problems?

I don’t expect Threads to have moderation issues which impact us, because the only Threads posts we will see in our timelines will be from Threads users which are followed by someone on our instance. Any problematic accounts on Facebook’s side of things will likely not be followed by us, so we’ll be unaware of them.

However, we will not take on the responsibility of moderating Threads users on Facebook’s behalf if it comes down to it. If moderation of Threads posts becomes a problem, we will likely limit Threads.net on a server-level. Limiting Threads would hide Threads posts and users from most areas, but would still allow you to individually follow and be followed by Threads users you choose.

But you block Twitter!

We block Twitter bridges like BirdsiteLIVE because they do not foster any sense of community. As a one-way mirror, replies and favorites aren’t reflected on Twitter’s side of things, which makes for a confusing experience, and essentially leaves us to host a read-only mirror of Twitter for free, which is neither cost-effective nor encourages Twitter users to switch to Mastodon.

Threads is different, because we expect two-way communication functionality to work as most people would expect. Your replies to Threads users on Mastodon should appear in the Threads app, etc. Threads users will also be more exposed to other fediverse platforms like Mastodon, and may likely be encouraged to switch due to features like chronological timelines and custom domains.

If Threads severely limits how Mastodon users can interact with Threads users, and vice-versa, we will reconsider blocking Threads at that time.

I have another question

Mastodon published a blog post which addresses Threads in further detail and how it will interact with Mastodon.

Please contact @[email protected] on Mastodon if you have any questions or wish to provide feedback. I’m not opposed to changing this policy if that is the overwhelming feedback, but I believe that the best approach for our communities specifically is a user-directed approach, so federating while providing the controls to adjust your personal exposure to Threads feels like the best way to move forward.