Does the #Bluesky bridge thing use some kind of odd `content-type` when requesting profile data?

[liaizon@social.wake.st]

@jdt this seems like it could use a @snarfed.org tag

[julian@activitypub.space]

liaizon@social.wake.st I pinged him, he says he can't respond yet because of the aforementioned connection negotiation issue!

jdt@enigmatick.social

[snarfed@activitypub.space]

Hey jdt@enigmatick.social, sorry for the trouble! We send Accept: application/activity+json, application/ld+json; profile="https://www.w3.org/ns/activitystreams", text/html; charset=utf-8; q=0.5 with our AP fetches, which seems to make enigmatick.social 303 redirect to the HTML profile page, eg /@jdt here.

(Sorry for the complicated Accept header! We get URLs from various places, so if a URL isn't an AP id, we want to fall back to handling it as HTML and find its AP object via a rel-alternate link.)

[jdt@enigmatick.social]

@julian@activitypub.space My guess is that his JSON processor is choking on a non-standard tag I have in my profile (e.g., keys or ephemeral.webfinger). I should clean up the latter since it's intended for client operations only.

But it is valid JSON either way. The ephemeral object might cause a JSON-LD parser to choke since I don't declare it in the @context.

[informapirata@activitypub.space]

jdt@enigmatick.social I'm sure julian will be able to solve this compatibility issue between NodeBB and Fedibridge together with snarfed@mas.to and when he does, it will be a great day for the Fediverse!

[jdt@enigmatick.social]

@julian@activitypub.space I think I see the issue on @snarfed's post on your site (thanks @snarfed). I don't currently handle application/activity+json requests for the URL (i.e., https://enigmatick.social/@jdt). I only handle those on the ID (i.e., https://enigmatick.social/user/jdt).

I don't see any harm in adding that to the URL, so I'll add a 301 to redirect application/activity+json requests for /@jdt to /user/jdt.

It's odd, though - my logs seem to indicate that the bridge server is requesting /user/jdt already.

[jdt@enigmatick.social]

@julian@activitypub.space I see the issue clearly now and can reproduce it (thanks @snarfed). It's just the complexity of the Accept header - I'll dig into why my nginx configuration isn't handling that well.

[jdt@enigmatick.social]

@jdt@enigmatick.social It's actually in my application code:

if let Some(accept) = headers.get(header::ACCEPT) {
    if let Ok(accept_str) = accept.to_str() {
        if accept_str.contains("text/html") {
            log::debug!("Redirecting to presentation page");
            return Ok(AbstractResponse::Redirect(Redirect::to(&format!(
                "/@{username}"
            ))));
        }
        if accept_str.contains("application/activity+json") {
            log::debug!("Returning application/activity+json");
            return Ok(AbstractResponse::ActivityJson(ActivityJson(actor)));
        }
        if accept_str.contains("application/ld+json") {
            log::debug!("Returning application/ld+json");
            return Ok(AbstractResponse::LdJson(LdJson(actor)));
        }
    }
}

Just a priority issue with the existence of text/html. I'll rearrange.

[jdt@enigmatick.social]

@jdt@enigmatick.social Fixed. My code handles the Accept header per RFC specifications now (i.e., by explicit weight first and by order second).

[jdt@enigmatick.social]

@julian@activitypub.space BTW, I love that your interface uses rich formatting for markdown code blocks - so many platforms just phone that bit in.

Enigmatick uses highlight.js too, so I tend to use that a lot.

[julian@activitypub.space]

jdt@enigmatick.social thanks! Yeah it was important to me to get that right. That little highlight library has been chugging along all this time lol.