It does not work on any Pleroma servers yet. But I believe that is an unintentional compatibility issue. However some servers seem to be outright blocked.
Let me explain. Threads requires signed fetches. What that means is that every GET request to a threads.net resource needs to be cryptographically signed. Threads will then look up the signer and verify its signature.
The request to Threads contains a signature, with information about how to verify it. Threads will then verify it by fetching info from the origin server before returning the data.
You can see Threads fetching your own server by looking at the "facebookexternalua" user agent. Try this command on your server:
grep facebookexternalua /var/log/nginx/access.log
If you see logs there, that means Threads is attempting to verify your signatures and allow you to access their data.
On Gleasonator, I am seeing logs there. It is trying to let me establish a connection, even though it fails due to a bug in Pleroma or Threads. This means Gleasonator is not blocked.
However, on Spinster, and the Mostr Bridge, I have no requests from Threads at all, despite sending signed fetches. graf reports that Poast also isn't receiving any requests.
I do not believe they are operating on a whitelist. If so, it wouldn't make sense for Gleasonator and many other widely-blocked servers like gameliberty.club to be able to fetch from Threads.
So then I thought it may just be a caching issue, or a fluke on their end. But when I make a request from Gleasonator, I get the pingback from Threads within seconds. On Spinster and Mostr, there is no attempt being made at all.
So I am starting to think they may be blocking at the server-level already. And they are blocking Poast, Spinster, and the Mostr Bridge.
@alex I also see attempts to fetch instance actor in my log, but the last one was ~5 hours ago. Now when I make a signed request, threads.net doesn't react at all, even if I send a signed request as a different actor.
@alex I tried to fetch https://www.threads.net/ap/users/mosseri from my other instance public.mitra.social and received a pingback from facebookexternalua. Is it possible that they block mitra.social but not public.mitra.social? Seems unlikely. I think their federation client may simply give up after several unsuccessful federation attempts.
@silverpill I am still getting recent requests from Threads, every time I fetch. This proves they didn't turn the service off. They're choosing to deny some requests, possibly by actor origin.
@silverpill I don't know why they would target mitra.social. Does mitra.social have any requests from their user-agent historically? I have 0 from servers that don't work, which means no attempts were ever made.