@julian just out of curiosity is it related to this funny looking thing?

https://wrong.webfinger-canary.fietkau.software/canary

@wronglang@bayes.club actually, no! That's a different Julian: @julian@fietkau.social <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f606.png?v=c7cc56fe415" title="" />

But it seems we have thought about the same problem.

... but it is great that you posted it! You've shared a common use-case for a webfinger resolution to a different domain... what @julian@fietkau.social calls the split-domain.

So in that case, a blanket rejection of a different domain isn't the right approach.

@julian@activitypub.space @wronglang Only kind of – I've never considered the implications of a server resolving a WebFinger query for a user on a different origin. At a glance I'm not sure if it solves more problems than it introduces.

What we do have is WebFinger results linking to ActivityPub actors on a different domain. Fun for things like static site redirects: https://www.hanselman.com/blog/use-your-own-user-domain-for-mastodon-discoverability-with-the-webfinger-protocol-without-hosting-a-server And it enables split-domain setups if the ActivityPub domain delegates its WebFinger lookups back to the WebFinger server.

@julian@fietkau.social the only way I can think of it conceivably working is if Webfinger(domain A) » Account (domain B) » name@domainA

So, a two-way back-reference.

@julian so, here's what RFC 7033 says:

"The host to which a WebFinger query is issued is significant. If the query target contains a "host" portion (Section 3.2.2 of RFC 3986), then the host to which the WebFinger query is issued SHOULD be the same as the "host" portion of the query target, unless the client receives instructions through some out-of-band mechanism to send the query to another host. "

@julian

" If the query target does not contain a "host" portion, then the client chooses a host to which it directs the query using additional information it has."

@julian so, I read that as "You should use the hostname from the webfinger unless you don't want to or it's not there." Your directory idea sounds fine. I could see using it as a high-performance cache, for example.

@evan@cosocial.ca boy, that second half does a bit of heavy lifting doesn't it <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f63c.png?v=c7cc56fe415" title="" />

@julian@activitypub.space Current split-domain setups (Mastodon, GTS etc) do the two-way verification like this: the domain A WebFinger result has a rel="self" ActivityPub link pointing to the actor on domain B, the domain B WebFinger query for user@domainB returns a result with subject: user@domainA. The actor document doesn't need to do anything special.

That said, FEP-2c59 has seen some uptake since I wrote @canary. I should update the text some time to reference it.

@julian srsly

@julian

I believe there was a questionably named “WebFist” protocol that allowed cross-server WebFinger.

https://indieweb.org/Webfist

@benpate@mastodon.social ROFL oh dear

@julian@fietkau.social thanks for summarizing the split domain dance for me.

Assuming this is how your canary is set up?

@julian@activitypub.space Yep! Compare

https://correct.webfinger-canary.fietkau.software/.well-known/webfinger?resource=acct:canary@correct.webfinger-canary.fietkau.software

and

https://wrong.webfinger-canary.fietkau.software/.well-known/webfinger?resource=acct:canary@wrong.webfinger-canary.fietkau.software

Note the self link and the subject. In a split-domain setup, the WebFinger results for both hostnames are identical, which is why server software often simply issues an HTTP redirect for ease of implementation.

For clarity, I didn't invent this, Mastodon came up with it (and respects it for profile views). I noticed while setting up earlier versions of @DailyRucks that Misskey does not. And so @canary was born.

@julian@activitypub.space Here's Mastodon's server admin documentation for the feature: https://docs.joinmastodon.org/admin/config/#web_domain And here's GoToSocial's: https://docs.gotosocial.org/en/latest/advanced/host-account-domain/

Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting. I've had a FediForum demo titled “None of you have any idea how close we already are to custom handle domains in profile settings” drafted in my head for years, I just can't find the time to put it together.

> @julian@fietkau.social said:
>
> Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting.

oooooooooh, now you have my attention.

@julian@activitypub.space Here's what Takahē has to say on the subject: https://docs.jointakahe.org/en/latest/domains/

Even they don't go all the way, they “only” let server admins add a selection of WebFinger domains for users to choose from.

So what if we put a “handle domain” field into people's account settings, let them enter whatever they want, and on submission we test whether that domain's WebFinger query for the username in question returns a valid result pointing back to our local actor?

I honestly think this would work.