This tool will tell you who on the Fediverse is following users on Threads.
To start, put a list of Fediverse accounts here.
This tool tracks users and instances that interact with Threads. It only looks at public data and only shows users who have opted into being discoverable.
Pyrex Panjakar. (@pyrex@dragon.style)
It's written in Go.
Because distributing Stop Using Threads as a desktop app would mean (1) only technical users get access (2) large amounts of duplicate traffic to most Fediverse instances.
Distributing it as a web app means I can deduplicate the traffic and throttle it to avoid overwhelming anyone's server. It also means I can turn it off if the service is abused.
I collect IPs for up to one hour to do rate limiting. I collect usernames, a single enum value representing the server's beliefs about your relationship to Threads, and a comment explaining the reason for those beliefs. No profile data or posts are duplicated to the database.
I don't collect data on any user unless someone puts their name in the box.
The tool generates less traffic than a standard Fediverse client. It follows the rate limiting guidelines from the Mastodon documentation by limiting itself to 60 requests per minute with no bursting.
That's fine!
Likely you already are excluded -- if you never opted into search, then you haven't opted into Stop Using Threads either.
Stop Using Threads supports all the standard bot opt-outs, and a few custom ones so your opt-out can be deniable to others. Specifically, you can do any of these things:
The tool will fix your status within a day. If you want to fix it faster, search yourself and click the "refresh" link.
That's fine and you're welcome to do so. Our user agent is:
ZUCKBLASTER/9000 (stop-using-threads.net)
If your robots.txt mentions us, we'll play it safe and not scrape you.
You can also write me on Mastodon and I'll manually add you to the exclusion list. You won't see any more network traffic from us after that.
Here is an exact description of Stop Using Threads's behavior:
This process designedly does less than 6 API calls per user, and therefore the service imposes a rate limit of 10 investigations per server per minute.
July 2023: Threads comes out. They run an influencer campaign that makes it look like leader-level figures in every industry have already adopted it. I talk to my coworkers about it. They believe in the campaign.
On December 12th, no one likes Threads, no one likes Mark Zuckerberg.
On December 13th, Threads starts federating.
On December 14th, my timeline is full of people, primarily concentrated on a handful of tech press-adjacent instances, who are convinced that resisting Facebook is futile, technically infeasible, and that their presence on the Fediverse might turn out to be fine, actually.
The campaign strikes me as incredibly similar to the very first release of Threads. Back then it was just people I knew in real life -- but now it feels like everyone I know online is saying the opposite of what they were saying a week ago.
The conclusion I draw from this is that Zuck is running a successful astroturfing campaign against the Fediverse as a whole using allies in tech leadership.
It disappoints me that it took less than twenty-four hours for them to convince so many people. It scares me.
I think Facebook's short-term strategy is something like this:
Facebook knows (but won't say) that ActivityPub doesn't give ordinary users a way to communicate their nonconsent. The only tool to communicate nonconsent is an instance-level block with authorized fetch.
I want those blocks to exist, and there's already a great campaign called Fedipact which is focused around getting them. But instance-level blocks are seen as a last resort mod action and Facebook is really good at getting the admins of big instances on their side. So I don't really expect them to materialize.
That means we need a strategy against Threads that works if admins are neutral, inactive, or even hostile. Such a strategy needs to be organized: it needs to create technical problems for Facebook's campaign to normalize itself, and it needs to produce a loud collective expression of nonconsent.
This program is not a complete strategy, but it's part of a larger existing campaign. I'm hoping for two things:
My hope is that mass blocks do not actually occur, for the same reason that writers weren't removed en masse for scabbing during the writers' strike.
Ultimately, I don't know what will solve the problem. This is the best thing I could think of. I hope it's better than nothing. If you don't like it, I hope you think of something better.
I don't think it's remotely important that the tool produce exhaustive output. If people are circumventing the tool, that means interacting with Threads is a source of public shame and the campaign is succeeding.
If I try to make circumvention hard, then the people who are trying to circumvent my tool will try harder to circumvent it. This is disrespectful of consent. And practically, any anti-circumvention measure I implement has a chance of doing damage to the servers I am interacting with, which would affect innocent users.
In the future, if Facebook engages in circumvention, I may target them specifically, but I won't take any more aggressive measures than this on any server not run by Facebook.
If a bunch of instances block Facebook, they'll be forced to respond in some way. It's possible they'll switch to scraping our data without consent.
I think this is fairly likely. But if they do it, and they're caught, all the goodwill goes out the window. Neutral parties won't want to work with them, they force a schism, and their Embrace/Extend/Extinguish gets much harder.
We can't force Facebook out of existence. Whatever we do, Facebook will find some way of responding to it. But that doesn't mean we should give them everything they want in the short term.
And based on what we know about what they're trying to do, instance blocks will force them to change their plan.
No. If they want to interact with Fediverse users, they should register on a Fediverse instance not run by Mark Zuckerberg.
The collective campaign against Threads creates an ankle-high barrier to an ocean of content. All we're asking for is that, if they're coming to the party, they don't invite him.
Only one Threads user has contacted me so far claiming to have been harmed: a blind person who said the Threads app is inaccessible and that they want to use Threads through Mastodon instead.
I can't help but point out, though, that Mastodon users and I aren't the ones harming them. By creating an app they can't use and offering Mastodon as an alternative, Zuck is effectively holding their access hostage unless their instancemates send him their data.
I told them to try mastodon.social and they told me mastodon.social's moderation is queerphobic and that offends them. This is a surprising complaint to me given that Threads still hosts Gays Against Groomers.
Anyway, the fact that closed-source software is terrible for disabled people is well-known among FOSS advocates and widely ignored by commercial software fans.
They would be less likely to have this problem if Zuck cared about blind people or if Threads had an open API. And maybe for a little while it will -- but if Facebook has a long-term goal of crushing the Fediverse, that API will go away.
There are many reasons a user might not be seen.
There are some other user exclusion conditions beyond the ones I included here. They won't affect you if you're not being evil.
I'm considering it. This would make the tool easier to use. However, there are two problems with it:
Obviously I'm cool with operating on people's follows, but I'm interposing multiple levels of anti-abuse code when I do that. I'm not cool with bulk-surfacing them in raw form or using them to power a discovery tool.
If you can solve these problems -- for instance, by doing everything client-side somehow -- let me know and I'll build the thing you want.
For now, a pretty good way to load your follows, if you use Mastodon, is to export them as CSV from the `https://your.instance/settings/export` page. Then you can load them in LibreOffice (or another spreadsheet application) and copy the list to my text box.
You can also contact me on Mastodon and I'll download your follows for you.
Automatically blocking a large group of people with no human input is usually harmful and frequently irreversible. Plus, I'm fairly likely to make a mistake and include names that don't belong -- for the first four hours of this tool's existence, two of the supported opt-out methods were broken.
Many people who interact with Threads may have good reasons to. When I was testing, I noticed a lot of people who were following @mosseri appeared to be Mastodon developers who, I think, had a rational interest in knowing what Facebook was up to. And I see some people following Threads, I suspect, specifically to see if my tool is working!
In my ideal world, that traffic wouldn't exist, but until instance-level blocks are in place, these users' traffic does not actually make the data ingestion problem worse. So for now, blocking all those people would be totally counterproductive!
I'm concerned about one other problem. That problem: in the future, it is likely Facebook will create a migration flow from the Fediverse to Threads. That means that if @x@your.instance migrates, everyone who followed them suddenly looks like a Threads-interactor. I don't want inactive users to get automatically blocked because their friends scabbed.
Based on all that stuff, I've made the opinionated choice not to generate a blocklist.
Yes, by giving money to LGBTQ causes.
Pyrex Labs 2023. Thanks to Kistaro Windrider for helping with the code. 🦇🦎