Skip to main content


Well there's nothing to do with Threads at the moment, unless someone can point to new profiles being fetched or posts coming through.

Back to writing my custom websocket pool.

I've seen exactly one profile being fetched on exactly one instance.
https://lor.sh/@mosseri@threads.net (will redirect when opening directly, so go to lor.sh and paste @mosseri@threads.net into search box)
AP actor URI is apparently https://www.threads.net/ap/users/mosseri/. Yet to see a single post.
Looks like he appeared on mastosoc as well.
https://mastodon.social/@mosseri@threads.net
And on gameliberty, which is definely not the kind of instance that'll be whitelisted.
https://gameliberty.club/web/@mosseri@threads.net
Yeah, I'm late. My running theory is that it might be expecting signed fetch with the same URL that's expected from mastodon (https://mastodon.tld/actor#main-key). Might test that out later.
Screenshot_20231214_192215.png
Screenshot_20231214_192215.png
@mintKeep me updated if you figure it out please.
@
Alright, I have a patch that allows me to use arbitrary actor URL and private key for signed fetches. I've just added an actor with the same structure as Mastodon's internal actor at https://instance.tld/actor, and spoofed the useragent to Mastodon's one. And it worked! Mosseri successfully federated to cum.salon.
Screenshot_20231214_194733.png
Screenshot_20231214_194733.png
This might possibly explain why you trying to fetch him from animalliberation.social failed: if you're logged in and try to search for some user's handle, Mastodon signs outgoing fetch requests with your own actor key instead of instance-wide one. Still, I'm getting "record not found" on /api/v1/accounts/lookup when logged out, but that might be because of your privacy settings or something.

@mintI implemented signed fetch on the Mostr bridge. Now it can fetch Threads objects from an ngrok instance. But mostr.pub still can't fetch. Not sure if IP block or because of cache on their end. We'll wait and see.

https://gitlab.com/soapbox-pub/mostr/-/merge_requests/76

@
Btw... Pleroma signs object fetches by default:
:pleroma, :activitypub, sign_object_fetches: true

What did you change @mint to make it work?
@
@mintSorry I just re-read your post. So it wouldn't work unless the actor was at /actor specifically? Mastodon user-agent doesn't seem to be required.
@
Yes, it should be at /actor. Not sure about useragent, I've tried fetching the profile with browser-like one and it returned HTML page, so I just changed it to mastodon one just to make it safe.

@mintIt's fetching /internal/fetch with the default setup on Pleroma/Rebased. I wonder it's just failing validation, like maybe because of the dot in the username.

On the other hand, some of my servers are not getting the requests at all... oof. I wonder if that means they're blocked.

@
>maybe because of the dot in the username
Can't be, /actor's nickname also has dots in it (e.g. mastodon.social@mastodon.social resolves to mastodon.social/actor).
@mintI figured it out. It's the lack of an "outbox" field. This fixes it: https://gitlab.com/soapbox-pub/rebased/-/merge_requests/296/diffs
@
@mint isn't it just "recommended" under the spec? not that that's a reason not to do what you're doing
@
@Moon @mintMitra was blocking posts from Mostr due to not having an outbox field a while back, and @silverpill told me outbox is required, so I went with that.
Here's the only hit in logs:
173.252.111.11 - - [14/Dec/2023:16:40:12 +0000] "GET /actor HTTP/1.1" 200 2113 "-" "facebookexternalua"

profiles can be viewed right now, I suspect that the test is only being extended to the #Threads engineers, admins, and devs rn

@mosseri@threads.net

@0xjessel@threads.net

@christophersu@threads.net