Recent searches
Search options
@thisismissem@hachyderm.ioLooks like we've some work todo: https://correct.webfinger-canary.fietkau.software/#implementation-status
Thanks to @julian for this fantastic research on ActivityPub + Webfinger addressing through split-domain setups.
i.e., @example@example.org => @example@social.example.org
Where by example.org/.well-known/webfinger redirects to social.example.org/.well-known/webfinger
I am curious if example.org responding directly but point self/profile-page to the subdomain would work too?
@thisismissem If I'm understanding you correctly then yes, that should work too. Setting WebFinger up on example.org as a redirect to social.example.org is the most convenient way to do it (since both need to serve identical content to establish the canonical handle), but as long as the WebFinger resource and reply are correct and matching on both domains, it should work just fine no matter the internals.
@julian aah, I was thinking of a case where social.example.org didn't respond to webfinger requests at all
@thisismissem Ah gotcha! AFAIK Mastodon checks whether the WebFinger result returned by social.example.org matches the one on example.org while establishing the canonical handle. If cooperation from social.example.org were not required, example.org would be able to change the actor's handle remotely.
But you can set up WebFinger on example.org without social.example.org needing to be aware of it if all you need is a redirect. Mastodon honors those. See here: https://www.hanselman.com/blog/use-your-own-user-domain-for-mastodon-discoverability-with-the-webfinger-protocol-without-hosting-a-server @shanselman
@julian @shanselman yeah, I just did a study on whether people support webfinger redirects or not, and if they don’t then do they use host-meta.
Like 2.1% of surveyed domains only supported host-meta redirects, not webfinger redirects.
@thisismissem I was following that thread. 
Great empirical work. I mention host-meta in my WebFinger explainer, but only as an afterthought.
@thisismissem But to loop back to your opening post one more time, IMHO the most pressing work Mastodon would need to do for this feature would be to adhere to the first item on my checklist, identifying actors by their ID instead of their name+server tuple.
If that was in the bag, it would obviate the need to set the handle domain before starting federation and it would enable per-user custom handle domains and potentially even user name changes without account moves. We can dream! 
@julian I'm not sure I follow this?
@thisismissem If Mastodon (and others) were to consistently use the AP ID everywhere to uniquely identify actors instead of their WebFinger "acct:" URIs, we could do away with the assumption that an actor's WebFinger details never change.
Mastodon, GTS, and Iceshrimp all say not to change the handle domain after initial setup, for federation reasons. I see the reliance on unchanging WebFinger info as a bug. Without it, you could do Bluesky-style custom handle domain and account name changes.
@julian the changing of the handle domain after you've already started federation is because all the previously published activities, objects, etc, will all still point to the old domain, so if you want to change the domain, you need to publish updates to literally everything.
This is part of a wider issue: https://github.com/w3c/activitypub/issues/473
@thisismissem The activities point to the ActivityPub domain, right? I don't want to change that, I just want to change the WebFinger domain. In a split-domain setup, handles are already derived from the WebFinger hostname, not the ActivityPub hostname.
@julian well, LOCAL_DOMAIN iirc, _is_ the activitypub hostname?
@julian oh, wait, no, that's WEB_DOMAIN that's in all the URIs in activities and objects.
@thisismissem I'm looking at the Mastodon docs for web domain / local domain and I can't shake the feeling there's a spot in the text where the two variables have been mixed up...
But let's look at an example actor: https://toot.kif.rocks/@team.json The handle domain, kif.rocks, appears nowhere in the actor document. It only appears in the WebFinger lookup process: https://toot.kif.rocks/.well-known/webfinger?resource=acct:team@toot.kif.rocks That's why I think we should be able to change it without jeopardizing federation.
@thisismissem Okay no, the docs are fine, I just find the naming of those two variables a bit inscrutable. 
Probably doesn't help that every AP project capable of split-domain setups calls them something different.
@julian mmm, yeah, maybe? I think the issue would be because the Actor doesn't include their webfinger domain, there's no way to issue an update saying “Hi @foo@social.example is now @foo@different.example”
So you'd likely end up potentially with two different accounts for the actor or you'd webfinger two different handles and get the same Actor?
@thisismissem True, in the absence of something like https://codeberg.org/fediverse/fep/src/branch/main/fep/2c59/fep-2c59.md I guess platforms would need to periodically refresh the WebFinger endpoint, same as profiles now.
Avoiding duplicated remote accounts comes back to consistently identifying and deduplicating actors based on their ID instead of their handle.
@julian yeah, that'd be awesome
@thisismissem @julian This is what I do for me@me.org and it's worked fine from what I can tell (you search for that, you get my actual account, and I've moved since). Mine is just a naive text file, no script.
The only thing it broke for me was it led us to a super interesting bug in GoToSocial that they fixed like a year or two ago, wherein if you searched for your spoofed webfinger from the instance your profile is on, your account would disappear until GtS was restarted. 
@fwaggle Oh, fun. 
I like that these WebFinger redirects can be set up through very simple means. But I'm particularly interested in the config where your ActivityPub platform is aware of your external WebFinger domain and is willing to cooperate to make it your canonical handle. Not every server software honors these kinds of setups on remote profiles though, and a few ActivityPub developers dislike them strongly. This is an opinionated project.
@julian @thisismissem Oh it's annoying that anyone wouldn't like it, because I think without a pile of work it's the closest thing to a portable identity we have?
@fwaggle Yes and no. There are other efforts (mainly https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md) that would provide actual portable identities, but changeable handles from split-domain configs would arguably be a smaller compatibility break, since software depending on unchanging handles is an implementation detail that's kind of unintended, whereas FEP-ef61's changes are a bit more fundamental and ask more effort of other implementations. So, kind of a bigger pile of work maybe.
