bsky.brid.gy users fail to resolve via WebFinger handle (@user@domain)

teidesu commented

2026-03-01 19:42:12 +00:00

Your setup

OTP

Extra details

nixos

Version

3.17.0

PostgreSQL version

16

What were you trying to do?

try opening /ostatus_subscribe?acct=@snarfed.bsky.social@bsky.brid.gy on any recent akkoma instance, notice the error:

What did you expect to happen?

the user resolves correctly

What actually happened?

there's an error

Logs

Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] GET /ostatus_subscribe
Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] Processing with Pleroma.Web.TwitterAPI.RemoteFollowController.follow/2
                                         Parameters: %{"acct" => "snarfed.bsky.social@bsky.brid.gy"}
                                         Pipelines: [:pleroma_html]
Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] QUERY OK source="oauth_tokens" db=0.3ms idle=610.4ms
                                       SELECT o0."id", o0."token", o0."refresh_token", o0."scopes", o0."valid_until", o0."user_id", o0."app_id", o0."inserted_at", o0."updated_at" FROM "oauth_tokens" AS o0 WHERE (o0."token" = $1) ["..."]
Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] Fetching object snarfed.bsky.social@bsky.brid.gy via AP [ap_id=false]
Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] Dereferencing AP doc
Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [error] Object rejected while fetching snarfed.bsky.social@bsky.brid.gy {:valid_uri_scheme, false}

Severity

I can manage

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup OTP ### Extra details nixos ### Version 3.17.0 ### PostgreSQL version 16 ### What were you trying to do? try opening `/ostatus_subscribe?acct=@snarfed.bsky.social@bsky.brid.gy` on any recent akkoma instance, notice the error: ![image](/attachments/ca62a894-866e-4702-8461-345c698650c9) ### What did you expect to happen? the user resolves correctly ### What actually happened? there's an error ### Logs ```shell Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] GET /ostatus_subscribe Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] Processing with Pleroma.Web.TwitterAPI.RemoteFollowController.follow/2 Parameters: %{"acct" => "snarfed.bsky.social@bsky.brid.gy"} Pipelines: [:pleroma_html] Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] QUERY OK source="oauth_tokens" db=0.3ms idle=610.4ms SELECT o0."id", o0."token", o0."refresh_token", o0."scopes", o0."valid_until", o0."user_id", o0."app_id", o0."inserted_at", o0."updated_at" FROM "oauth_tokens" AS o0 WHERE (o0."token" = $1) ["..."] Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] Fetching object snarfed.bsky.social@bsky.brid.gy via AP [ap_id=false] Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [debug] Dereferencing AP doc Mar 01 22:32:49 kennel akkoma[263132]: request_id=GJjOj4lvnAMPvHIAAA-H [error] Object rejected while fetching snarfed.bsky.social@bsky.brid.gy {:valid_uri_scheme, false} ``` ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

image.png

52 KiB

teidesu added the

bug

label

2026-03-01 19:42:12 +00:00

teidesu changed title from ~~[bug] bsky.brid.gy doesn't work~~ to [bug] bsky.brid.gy users fail to resolve

2026-03-01 19:42:23 +00:00

teidesu commented

2026-03-01 19:44:40 +00:00

Author

this might be a bug on bridgy side, but mastodon seems to be working fine.

i haven't found the specific place in the codebase this error stems from, but if i were to guess - it tries to parse the alsoKnownAs field from the actor document (which is did:plc:blabla or did:web:blabla for bsky bridgy users), and the protocol check fails:

curl https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb -L -H "Accept: application/ld+json"

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.archive.org/miscellany",
    {
      "discoverable": "http://joinmastodon.org/ns#discoverable",
      "indexable": "http://joinmastodon.org/ns#indexable"
    },
    {
      "PropertyValue": "http://schema.org#PropertyValue",
      "value": "http://schema.org#value"
    },
    {
      "alsoKnownAs": {
        "@id": "as:alsoKnownAs",
        "@type": "@id"
      }
    },
    "https://w3id.org/security/v1"
  ],
  "alsoKnownAs": [
    "did:plc:3ljmtyyjqcjee2kpewgsifvb"
  ],
  "attachment": [
    {
      "name": "Web site",
      "type": "PropertyValue",
      "value": "<a rel=\"me\" href=\"https://bsky.app/profile/snarfed.bsky.social\"><span class=\"invisible\">https://</span>bsky.app/profile/snarfed.bsky.social</a>"
    }
  ],
  "discoverable": true,
  "endpoints": {
    "sharedInbox": "https://bsky.brid.gy/ap/sharedInbox"
  },
  "featured": {
    "id": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/featured",
    "orderedItems": [
      "https://bsky.brid.gy/convert/ap/at://did:plc:3ljmtyyjqcjee2kpewgsifvb/app.bsky.feed.post/3lbi2vwntos22"
    ],
    "totalItems": 1,
    "type": "OrderedCollection"
  },
  "followers": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/followers",
  "following": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/following",
  "icon": {
    "type": "Image",
    "url": "https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu"
  },
  "id": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb",
  "image": {
    "type": "Image",
    "url": "https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu"
  },
  "inbox": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/inbox",
  "indexable": true,
  "manuallyApprovesFollowers": false,
  "monetization": "https://www.patreon.com/c/ANewSocial",
  "name": "Follow snarfed.org instead!",
  "outbox": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/outbox",
  "preferredUsername": "snarfed.bsky.social",
  "publicKey": {
    "id": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb#key",
    "owner": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAueuMf5qoIZFenIj/HeAE\nghfNTiJG+jj6jxEUrpKIDim8sCXdUY5gKzetr4VTqpKQzeQUKgph3wL3TdiXXX1x\n/nEyPKIktb3/NcM7YMzSwNwWkOPNxVq4pP36vGdu5ztgpyRcGAW71GOK8CVLa1az\nzQd+QDkgVx5BGiq00BQpuw5mImb7igyXv7+fuq70qQlLKaUa42yAxcf2xlg2Ewky\ng4ERf1z8JDpptLMx7/OUJdd9HqLeZxZsFCImTatBxnC93sFV3HVJBLa51tkkmgzt\n1EKGSW6ZOVB/ETDw0PA4EHU6wIVaJB3KRtfspoahgDZCFIlIqsK6L0eFVPBdYF/N\nxQIDAQAB\n-----END PUBLIC KEY-----"
  },
  "summary": "foo bar baz biff<br><br>\ud83c\udf09 <a href=\"https://fed.brid.gy/bsky/snarfed.bsky.social\">bridged</a> from \ud83e\udd8b <a href=\"https://bsky.app/profile/snarfed.bsky.social\">snarfed.bsky.social</a>, follow <a class=\"h-card u-author mention\" rel=\"me\" href=\"https://bsky.brid.gy/bsky.brid.gy\" title=\"@bsky.brid.gy@bsky.brid.gy\">@bsky.brid.gy</a> to interact",
  "type": "Person",
  "url": "https://bsky.brid.gy/r/https://bsky.app/profile/snarfed.bsky.social"
}

this *might* be a bug on bridgy side, but mastodon seems to be working fine. i haven't found the specific place in the codebase this error stems from, but if i were to guess - it tries to parse the `alsoKnownAs` field from the actor document (which is `did:plc:blabla` or `did:web:blabla` for bsky bridgy users), and the protocol check fails: ```bash curl https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb -L -H "Accept: application/ld+json" ``` ```json { "@context": [ "https://www.w3.org/ns/activitystreams", "https://purl.archive.org/miscellany", { "discoverable": "http://joinmastodon.org/ns#discoverable", "indexable": "http://joinmastodon.org/ns#indexable" }, { "PropertyValue": "http://schema.org#PropertyValue", "value": "http://schema.org#value" }, { "alsoKnownAs": { "@id": "as:alsoKnownAs", "@type": "@id" } }, "https://w3id.org/security/v1" ], "alsoKnownAs": [ "did:plc:3ljmtyyjqcjee2kpewgsifvb" ], "attachment": [ { "name": "Web site", "type": "PropertyValue", "value": "<a rel=\"me\" href=\"https://bsky.app/profile/snarfed.bsky.social\"><span class=\"invisible\">https://</span>bsky.app/profile/snarfed.bsky.social</a>" } ], "discoverable": true, "endpoints": { "sharedInbox": "https://bsky.brid.gy/ap/sharedInbox" }, "featured": { "id": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/featured", "orderedItems": [ "https://bsky.brid.gy/convert/ap/at://did:plc:3ljmtyyjqcjee2kpewgsifvb/app.bsky.feed.post/3lbi2vwntos22" ], "totalItems": 1, "type": "OrderedCollection" }, "followers": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/followers", "following": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/following", "icon": { "type": "Image", "url": "https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu" }, "id": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb", "image": { "type": "Image", "url": "https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu" }, "inbox": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/inbox", "indexable": true, "manuallyApprovesFollowers": false, "monetization": "https://www.patreon.com/c/ANewSocial", "name": "Follow snarfed.org instead!", "outbox": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/outbox", "preferredUsername": "snarfed.bsky.social", "publicKey": { "id": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb#key", "owner": "https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb", "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAueuMf5qoIZFenIj/HeAE\nghfNTiJG+jj6jxEUrpKIDim8sCXdUY5gKzetr4VTqpKQzeQUKgph3wL3TdiXXX1x\n/nEyPKIktb3/NcM7YMzSwNwWkOPNxVq4pP36vGdu5ztgpyRcGAW71GOK8CVLa1az\nzQd+QDkgVx5BGiq00BQpuw5mImb7igyXv7+fuq70qQlLKaUa42yAxcf2xlg2Ewky\ng4ERf1z8JDpptLMx7/OUJdd9HqLeZxZsFCImTatBxnC93sFV3HVJBLa51tkkmgzt\n1EKGSW6ZOVB/ETDw0PA4EHU6wIVaJB3KRtfspoahgDZCFIlIqsK6L0eFVPBdYF/N\nxQIDAQAB\n-----END PUBLIC KEY-----" }, "summary": "foo bar baz biff<br><br>\ud83c\udf09 <a href=\"https://fed.brid.gy/bsky/snarfed.bsky.social\">bridged</a> from \ud83e\udd8b <a href=\"https://bsky.app/profile/snarfed.bsky.social\">snarfed.bsky.social</a>, follow <a class=\"h-card u-author mention\" rel=\"me\" href=\"https://bsky.brid.gy/bsky.brid.gy\" title=\"@bsky.brid.gy@bsky.brid.gy\">@bsky.brid.gy</a> to interact", "type": "Person", "url": "https://bsky.brid.gy/r/https://bsky.app/profile/snarfed.bsky.social" } ```

Oneric commented

2026-03-02 01:40:21 +00:00

Owner

The initial fetch error from your logs is expected and unrelated to the parsing failure *(note how it tries to do a web request for the @ handle). The did: aliases also just get gracefully stripped and do not prevent parsing the user.

This is a bug in Bridgy’s WebFinger response. We request a webfinger response with Accept: application/xrd+xml,application/jrd+json and bridgy responds with Content-Type: application/xrd+xml; charset=utf-8. However, the XML they serve is invalid mis-casing all attributes (XML is case sensitive!)

Mastodon likely just prefers and gets served JSON instead and JSON (whose attributes are also case-sesnitive) appear to be currently not buggy in Bridgy.

<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

    <Subject>acct:snarfed.bsky.social@bsky.brid.gy</Subject>
    
    <Alias>https://bsky.app/profile/snarfed.bsky.social</Alias>
    

    
    <Link rel='http://webfinger.net/rel/profile-page' type='text/html' href='https://bsky.app/profile/snarfed.bsky.social' />
    
    <Link rel='http://webfinger.net/rel/avatar' type='' href='https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu' />
    
    <Link rel='canonical_uri' type='text/html' href='https://bsky.app/profile/snarfed.bsky.social' />
    
    <Link rel='self' type='application/ld+json; profile="https://www.w3.org/ns/activitystreams"' href='https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb' />
    
    <Link rel='self' type='application/activity+json' href='https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb' />
    
    <Link rel='inbox' type='application/ld+json; profile="https://www.w3.org/ns/activitystreams"' href='https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/inbox' />
    
    <Link rel='sharedInbox' type='application/ld+json; profile="https://www.w3.org/ns/activitystreams"' href='https://bsky.brid.gy/ap/sharedInbox' />
    
    <Link rel='http://ostatus.org/schema/1.0/subscribe' type='' href='' />
    
</XRD>

The initial fetch error from your logs is expected and unrelated to the parsing failure *(note how it tries to do a web request for the `@` handle). The `did:` aliases also just get gracefully stripped and do not prevent parsing the user. This is a bug in Bridgy’s WebFinger response. We request a webfinger response with `Accept: application/xrd+xml,application/jrd+json` and bridgy responds with `Content-Type: application/xrd+xml; charset=utf-8`. However, the XML they serve is invalid mis-casing all attributes (XML is case sensitive!) Mastodon likely just prefers and gets served JSON instead and JSON (whose attributes are also case-sesnitive) appear to be currently not buggy in Bridgy. ``` <?xml version='1.0' encoding='UTF-8'?> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'> <Subject>acct:snarfed.bsky.social@bsky.brid.gy</Subject> <Alias>https://bsky.app/profile/snarfed.bsky.social</Alias> <Link rel='http://webfinger.net/rel/profile-page' type='text/html' href='https://bsky.app/profile/snarfed.bsky.social' /> <Link rel='http://webfinger.net/rel/avatar' type='' href='https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu' /> <Link rel='canonical_uri' type='text/html' href='https://bsky.app/profile/snarfed.bsky.social' /> <Link rel='self' type='application/ld+json; profile="https://www.w3.org/ns/activitystreams"' href='https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb' /> <Link rel='self' type='application/activity+json' href='https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb' /> <Link rel='inbox' type='application/ld+json; profile="https://www.w3.org/ns/activitystreams"' href='https://bsky.brid.gy/ap/did:plc:3ljmtyyjqcjee2kpewgsifvb/inbox' /> <Link rel='sharedInbox' type='application/ld+json; profile="https://www.w3.org/ns/activitystreams"' href='https://bsky.brid.gy/ap/sharedInbox' /> <Link rel='http://ostatus.org/schema/1.0/subscribe' type='' href='' /> </XRD> ```

❤️ 1

Oneric closed this issue

2026-03-02 01:40:21 +00:00

Oneric changed title from ~~[bug] bsky.brid.gy users fail to resolve~~ to bsky.brid.gy users fail to resolve via WebFinger handle (@user@domain)

2026-03-02 01:40:40 +00:00

Oneric added

not our bug

and removed

bug

labels

2026-03-02 01:40:58 +00:00

teidesu commented

2026-03-02 01:59:25 +00:00

Author

thanks for looking into this!! for history: i notified bridgy maintainers here

thanks for looking into this!! for history: i notified bridgy maintainers [here](https://github.com/snarfed/bridgy-fed/issues/374#issuecomment-3981586422)

Oneric commented

2026-03-02 02:23:05 +00:00

Owner

small correction: the XML utility i put Bridgy’s response into after determining it failed to parse automatically switched to "HTML mode" and since HTML prefers lowercase thus complained about casing (while i assumed it checked against the referenced XRD spec). However after checking spec and our own XML response, the casing itself is actually fine.
Using another linter, the real problem is this Link with an explicitly empty type:

  <Link rel='http://webfinger.net/rel/avatar' type='' href='https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlobdid=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu' />

I can confirm deleting this Link element allows the response to be parsed successfully

small correction: the XML utility i put Bridgy’s response into after determining it failed to parse automatically switched to "HTML mode" and since HTML prefers lowercase thus complained about casing (while i assumed it checked against the referenced XRD spec). However after checking spec and our own XML response, the casing itself is actually fine. Using another linter, the real problem is this `Link` with an explicitly empty type: ```xml <Link rel='http://webfinger.net/rel/avatar' type='' href='https://morel.us-east.host.bsky.network/xrpc/com.atproto.sync.getBlobdid=did:plc:3ljmtyyjqcjee2kpewgsifvb&cid=bafkreicue4wpltjukuzi2dvaidbenyzfff43w7tbbbbuez6xmwsaiyrzuu' /> ``` I can confirm deleting this `Link` element allows the response to be parsed successfully

snarfed commented

2026-03-02 02:42:10 +00:00

Hi @Oneric! Aha, thanks, empty type makes more sense than mismatched case. Will fix.

snarfed commented

2026-03-02 03:15:55 +00:00

Fixed!

Oneric referenced this issue

2026-03-02 17:43:05 +00:00

twitter_api/remote_follow: allow leading @ in nicknames #1076

Oneric commented

2026-03-02 18:43:58 +00:00

Owner

Sorry if this caused confusion, but "with an explicitly empty type" was only meant to identify the offending element.
While an explicitly empty type is odd, empty string attributes certainly are generally allowed in XML so this is not what makes the response illegal XML.
I suspect it’s a lack of escaping in the URL. XML uses &something; escape sequences in strings and &, < and the character used for quotation MUST be escaped in this manner. The URL in the offending element contains a raw &, thus making it illegal in any spec compliant XML parser. But best just run an XML linter on the updated response in case there are more issues lurking until the linter is happy.

(Also current akkoma stable may need the remote subscribe to be called without a leading @ in nicknames but if so this is already fixed on develop)

Sorry if this caused confusion, but "with an explicitly empty type" was only meant to identify the offending element. While an explicitly empty type is odd, empty string attributes certainly are generally allowed in XML so this is not what makes the response illegal XML. I suspect it’s a lack of escaping in the URL. XML uses `&something;` escape sequences in strings and `&`, `<` and the character used for quotation MUST be escaped in this manner. The URL in the offending element contains a raw `&`, thus making it illegal in any spec compliant XML parser. But best just run an XML linter on the updated response in case there are more issues lurking until the linter is happy. (Also current akkoma stable may need the remote subscribe to be called without a leading `@` in nicknames but if so this is already fixed on develop)

snarfed commented

2026-03-02 20:00:31 +00:00

Ah! Good point about escaping, thanks for the catch. I've fixed that now too.

teidesu commented

2026-03-02 22:15:47 +00:00

Author

yeah seems to be working fine now :3
thanks <3

yeah seems to be working fine now :3 thanks <3

🎉 1

Rows
Columns

bsky.brid.gy users fail to resolve via WebFinger handle (@user@domain) #1074

Your setup

Extra details

Version

PostgreSQL version

What were you trying to do?

What did you expect to happen?

What actually happened?

Logs

Severity

Have you searched for this issue?