WebFinger doesn't allow querying by actor uri

[zotanmew]

Heya, the Pixelfed WebFinger implementation currently doesn't appear to support querying by ?resource=https://instance.tld/users/username. This is required for spec-compliance, and therefore federation with several other ActivityPub implementations that fail to resolve Pixelfed users without this. It'd be appreciated if you could add this!

[trwnh]

this is not required. which implementations are having issues, and what are the issues?

[zotanmew]

Iceshrimp.NET currently can't resolve pixelfed users for this reason. I'll check the spec again to be sure, I may be mistaken.

[zotanmew]

If i'm reading the spec correctly, it specifies that URIs under aliases identify the same entity as subject. (section 4.4.2). I'd conclude from this that they should be usable as a query target URI /resource as per section 4.1. Mastodon/pleroma/misskey/gotosocial all implement it in this way as well, though they presumably don't rely on it.

[zotanmew]

The reason we're querying the uri via webfinger is that it's the only way to obtain information on the split-domain configuration of the remote instance (whereby the accounts are registered under @instance.tld but the instance is reachable under web.instance.tld or similar)

[trwnh]

should, not must

the way you set up different web-domain and local-domain is to redirect webfinger requests from local-domain to web-domain

but you already have the id of the user so you do something like this:

• do a webfinger for acct:preferredUsername@webdomain against webdomain
• you should get redirected to the same query against localdomain
• if the self-link points back to the id you started with, take the subject

https://swicg.github.io/activitypub-webfinger/#reverse-discovery

https://docs.joinmastodon.org/admin/config/#web_domain

https://docs-develop.pleroma.social/backend/configuration/how_to_serve_another_domain_for_webfinger/#configuring-webfinger-domain

https://docs.gotosocial.org/en/latest/advanced/host-account-domain/

[zotanmew]

My point is that with the way the code is currently structured, WebFinger always comes before the AP fetch. Refactoring this would take ages & I'm sure we won't be the last implementation having issues like this. Would it be that difficult to check whether the resource being queried points to a local user? I can even send a PR if required, though my PHP is very rusty.

[trwnh]

webfinger shouldn't be necessary if you already have the actor id. how hard is it to just skip webfinger? something like the following pseudocode:

def get_actor_document(x):
  if x.startswith('https'):
    actor_document = get(x, headers={'accept': 'application/ld+json; profile="https://www.w3.org/ns/activitystreams"'})

  else:
    username, domain = x.split('@', 2)
    jrd = get(f'https://{domain}/.well-known/webfinger?resource=acct:{username}@{domain}', headers={'accept': 'application/jrd+json'})
    actor_id = filter(jrd, rel='self').href
    actor_document = get(actor_id, headers={'accept': 'application/ld+json; profile="https://www.w3.org/ns/activitystreams"'})

then you can construct the webfinger acct: uri following reverse discovery, in order to verify it

[zotanmew]

The issue is that using this you cannot figure out the canonical domain for a split domain user, since the AP payload never tells you what it's supposed to be. You have to webfinger the URI to do this. You can't even ask the remote instance for ?resource=preferredUsername after fetching it, because on AP platforms like takahe there may be more than one user with the same preferredUsername, on different accountDomains.

[zotanmew]

It'd be a lot of work to refactor this logic on my side, and it would just be one extra check (starts with http/s) and db query on your end.

Also, specifications are one thing in ActivityPub, we all know that to federate with everyone you have to implement what everyone else does, which isn't necessarily what the spec says. In this case, all the major implementations support this, so whether the spec says it's required or not, supporting it is a good idea regardless to ensure compatibility.

[trwnh]

you cannot figure out the canonical domain for a split domain user

you can. do reverse discovery.

to be clear, this is what it looks like when you do forward discovery and then verify with reverse discovery:

forward discovery

• start with a@trwnh.com
• do a webfinger for that acct: at that host, e.g. https://trwnh.com/.well-known/webfinger?resource=acct:a@trwnh.com
• take the self link which can be something like https://ap.trwnh.com/actors/1

reverse discovery

• start with https://ap.trwnh.com/actors/1
• extract preferredUsername a and hostname ap.trwnh.com, do a webfinger at e.g. https://ap.trwnh.com/.well-known/webfinger?resource=acct:a@ap.trwnh.com
• make sure the self link matches the actor you started with
• take the JRD subject as canonical

this shouldn't be hard. it's what "all the major implementations" do to get your canonical webfinger address.

You have to webfinger the URI to do this

no, you webfinger the preferredUsername@web_domain. you shouldn't have to webfinger the https uri for an actor under any circumstances.

[zotanmew]

I'm aware how this works, I've talked to people who co-wrote the AP spec. I can assure you that this is anything but easy to implement on our side.

We'd have to refactor several hundreds of lines of code that was really annoying to get right to begin with, to support a quirk of a different piece of AP software, that diverges from what mastodon does. I'm not going to spend several days rewriting hundreds of lines of critical federation code just to federate with Pixelfed.

Again, I'm happy to write a PR for this, I don't understand why you're so reluctant to make/merge this tiny compatibility change that would allow for federation with more services.

[trwnh]

the change isn't unwelcome, but i'm trying to point out that you are probably going to have issues in the future like this, and there's a high chance you're overcomplicating your code by doing something you shouldn't be doing. if it's "hundreds of lines" as you say, then that's almost certainly the case.

[rimu]

This would be really simple on the pixelfed side:

        query = request.args.get('resource')  # e.g. query value: "acct:alice@tada.club"
        if 'acct:' in query:
            actor = query.split(':')[1].split('@')[0]  # alice
        elif 'https:' in query or 'http:' in query:
            actor = query.split('/')[-1]                        # alice
        else:
            return 'Webfinger regex failed to match'

it's maybe 3 extra lines.

[dansup]

@rimu @zotanmew I just shipped support for this, feel free to re-open if you run into any issues. This is live on pixelfed.social if you want to test it btw!

[zotanmew]

@dansup thank you so much! one tiny nitpick (though I'm happy to add support for this on our end Update: added support for it on our end.) is that one of the aliases (instance.tld/username) still causes webfinger to return 400. Would be nice if you could add that, though it's not critical. The patch as-is fixed most of our federation issues with pixelfed, and the ones that remain I can easily work around on our end. Thanks again!