Why can't I load https://mastodon.social/@alice@social.sgo.to?

I’m trying to get my instance up and running, but I’m stuck at having my users discovered.

I think I got the basics right, but I’m still unable to load my users in different instances.

For example:

curl “https://social.sgo.to/.well-known/webfinger?resource=acct:@alice@social.sgo.to

{“subject”:“acct:@alice@social.sgo.to”,“links”:[{“rel”:“self”,“type”:“application/activity+json”,“href”:“https://social.sgo.to/@alice”}]}

curl --header “Accept: application/activity+json” https://social.sgo.to/@alice

Both of these resources seem right, but this doesn’t seem to be working for me:

Any ideas what might be going on?

maybe it’s Content-Type: application/activity+json; charset=utf-8? it’s possible that mastodon might not be expecting the charset parameter

1 Like

Ah, important clarification: I’m not even seeing the webfinger request being made to my HTTP server.

are you serving the webfinger endpoint with Access-Control-Allow-Origin: * or similar? and is the Content-Type: application/jrd+json?

My webfinger endpoint does not return neither Access-Control-Allow-Origin: * nor Content-Type: application/jrd+json, let me give that a try.

But, I’m not even seeing the request being made to my server.

Since you mentioned Access-Control-Allow-Origin: *, does Mastodon send preflight OPTIONS HTTP requests? Could that be the reason why it is not making a GET request?

A couple more data points:

This succeeds:
https://w3c.social/api/v1/accounts/lookup?acct=alice%40social.sgo.to

This fails:
https://mastodon.social/api/v1/accounts/lookup?acct=alice%40social.sgo.to

I’m wondering if the mastodon instances cache the webfinger requests in some way.

Hi Sam. In general, yes, mastodon does cache quite a bit :confused:

You might find this tool useful to test. Looks like it is able to resolve your webfinger. @alice@social.sgo.to · BrowserPub · A browser for exploring ActivityPub and the fediverse

For others, here is a ts function I’ve used in the past to generate JRD that was discoverable by Mastodon. This builds an http response body that I had sent with an http header Content-Type: application/jrd+json (no header value params or ‘;’)

function createJsonResourceDescriptorForActor(
	subject: `acct:${string}@${string}`,
	activityPubActorUrl: URL,
) {
	return {
		subject,
		aliases: [
			activityPubActorUrl,
		],
		links: [
			{
				rel: 'http://webfinger.net/rel/profile-page',
				type: 'text/html',
				href: activityPubActorUrl,
			},
			{
				rel: 'self',
				type: 'application/activity+json',
				href: activityPubActorUrl,
			}
		],
	};
}

Also here is fedify’s code for generating a response that works with mastodon’s quirks. fedify/src/webfinger/handler.ts at 451def15df40bf08d3d38830d3f132b22994090d · dahlia/fedify · GitHub

Obviously I’m sympathetic to why folks want to interop with Mastodon’s choices, but If I may grump: ActivityPub doesn’t mention ‘webfinger’ at all, and I find it unfortunate so many people use strings that aren’t links/URIs like @beng@mastodon.social to refer people on the social web instead of Actor URLs like the ActivityPub spec affords for e.g. bengo (@bengo@mastodon.social) - Mastodon.

1 Like

Ha, @alice@social.sgo.to · BrowserPub · A browser for exploring ActivityPub and the fediverse is pretty neat indeed, thanks for sharing that!!!

Hi Sam. In general, yes, mastodon does cache quite a bit

I’m suspicious about caching too, but when I try with completely independent instances, I still see the webfinger request not being made. Example:

https://mas.to/@bob@social.sgo.to

and

https://mastodon.world/@alice@social.sgo.to

I don’t see any webfinger request being made in my logs.

Does anything happen before webfinger?

I just searched for ‘@alice@social.sgo.to’ on mastodon.social and it seems to work?

Also the link above you said doesn’t work seems to for me now:
https://mastodon.social/api/v1/accounts/lookup?acct=alice%40social.sgo.to

In protocol? shouldn’t. On Mastodon in particular? not to my knowledge

At risk of being pedantic (but as a conformance testing nerd), heads up:

The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type in order to retrieve the activity.

I’m happy to see this also works :love_you_gesture:

curl --header 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' https://social.sgo.to/@alice
1 Like

It does indeed for me too! So weird! Must have been caching?

Any chance you can tell why:

(a) the profile picture isn’t loading? and
(b) the outbox posts aren’t loading?

We spoke more in the hallway at TPAC and I mentioned the great fedify library that @hongminhee has built.

Here is a link to a toy server implementing it at the point where you’d read from the mongo db you mentioned. activitypub-testing-fedify/server.ts at 0b7da32ba454b1928dc1c11c9b218abfb706d92e · gobengo/activitypub-testing-fedify · GitHub

The fedify tutorial is really good! Learning the basics of Fedify | Fedify

Looking forward to fedify also implementing ActivityPub C2S :slight_smile:

2 Likes

I don’t have a link handy but after wrestling for a long time with this over many years, I learned that mastodon didn’t fetch new actor’s outboxes to show posts unless/until some other actor hosted on that mastodon server had followed the actor. Only then would the server take on the burden of storing a copy of that remote actor’s outbox items. And in general (iiuc) mastodon prefers to only serve from it’s local cache of stored things vs just go fetch the outbox on-demand to render them in its UI but without storing them in the DB.

ngl it was tedious enough to reverse engineer all this out of mastodon issues and reading code that I never want to do it again :stuck_out_tongue:

1 Like

Ok, just to report back on this thread, 2 days in and I’m ready to give up making mastodon.social reliably happy. I’ll look at this again in a year or so:

1 Like