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

jdt@enigmatick.social

Does the #Bluesky bridge thing use some kind of odd content-type when requesting profile data? I'm seeing these errors in my logs when my server tries to retrieve posts (as part of my reply retrieval functions):

[2025-12-09T00:59:33Z ERROR enigmatick::retriever] Failed to fetch object from remote. URL: https://bsky.brid.gy/convert/ap/at://did:plc:oofa3qqoiszsmajbigfqskqv/app.bsky.feed.post/3m7egmddbwk2h, Status: 502 Bad Gateway, Body: <!doctype html>
    <html lang=en>
    <title>502 Bad Gateway</title>
    <h1>Bad Gateway</h1>
    <p>Couldn't fetch https://enigmatick.social/user/jdt as ActivityStreams 2: Couldn't decode as JSON</p>

If I'm reading that right, my retriever is failing because the bridge is trying to retrieve my profile and can't convert it to JSON. But I verified that my profile is provided as JSON for requests with these Accept header types:

application/json
application/activity+json
application/ld+json
application/ld+json; profile="https://www.w3.org/ns/activitystreams

...so I can't figure out what it's complaining about. I'll need to watch my varnish logs to see if I can capture one of the requests live from that perspective.

#ActivityPub

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.