It's a bit technical for just anybody to do it, but I could conceivably see a simple nginx config set up to serve just one record.....

Would be incredibly cool to see per-account WebFinger-based custom handle domains in a major platform!

@julian@activitypub.space

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.

oooooooooh, now you have my attention.

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.

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.

Assuming this is how your canary is set up?

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

https://indieweb.org/Webfist

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

" 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."

"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. "

So, a two-way back-reference.

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.

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

But it seems we have thought about the same problem.

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