[Webfinger][Webfinger] is used on the fediverse to abstract out variations in [ActivityPub][ActivityPub] actor URL formats, giving a uniform way of addressing an actor. With a Webfinger address, a client can discover the actor’s ActivityPub actor URL. This specification defines an explicit way to reverse the process, and discover a preferred Webfinger address from an ActivityPub actor URL.
@evan, the domain name in the property looks redundant, what if it doesn’t match the actor profile host?
I would recommend focussing on the local part and thus be local to the domain of the actor profile. Like Yaron Minsky recommends, don’t represent undesired state.
Is there a usecase for cross-domain?
The Motivation section goes into this in detail. The whole point is to allow cases where the Actor profile URL server part doesn’t match the Webfinger domain part.
why should redirects be forbidden? That sounds odd for a http protocol.
Redirects are forbidden to make confirmation of the link somewhat easier. If the actor URL is included exactly in the JRD document, you can confirm the correctness of the link with a string comparison, instead of following a bunch of redirects.
I’m just curious. Was the existing as:alsoKnownAs considered for this purpose? I know Mastodon uses it as part of its actor move functionality, but it seems like it could be used in a more general way than that (more general than Webfinger, but useful for that purpose too).
This could be used to resolve any of the values in as:alsoKnownAs to the actor URI using Webfinger or some other resolver. I’ve been considering also using this for non-actor objects to resolve alternative identifiers for objects in general.
I realize this may not address some implementation-specific issues when one of the AKAs is an internal account id for that implementation. I assume there would be internal ways to map the identifiers in those cases (like Mastodon’s statuses table that can map between account identifiers and actor URLs).
The meaning of alsoKnownAs property is not well-defined. In my opinion, it should be used to describe different resources linked to the same entity (example: two actors representing the same person), this is how Mastodon uses it and how it is used in FEP-c390.
it shouldn’t be used to describe different identifiers of the same resource (e.g. actor ID and a corresponding acct URI), for that I’m proposing aliases property (in FEP-ef61).
For alsoKnownAs, I just don’t know what the interaction with the Mastodon Move function would be. If it would interfere, I don’t think it makes sense to put forward a proposal for it.
sorry to say, but that’s an important part what http is about. Welcome to networking in a volatile, changing world. Redirects are an integral part of TimBls idea of cool uris don’t change. They are crucial http semantics.
I don’t think redirects are an important part of what JRD is. The point of the Webfinger lookup is to retrieve a canonical ActivityPub actor ID, not an URL for getting an ActivityPub actor profile.
I don’t think cool URIs not changing has anything to do with it. Tim Berners-Lee never wrote anything about how JRD links items shouldn’t change.
that’s a circular explanation rephrasing the question.
There’s a long motivation section in the document.
What’s the usescase for differing domains?
It’s the same use case as for using mro@domain.tld as your email address, rather than mro@mailserver.domain.tld. It lets organizations host their social server separate from their main Web site, but still use name@organization.tld as the Webfinger address.
The href should be exactly the same as the id of the actor. A client can confirm that the Webfinger address points to the ActivityPub actor without re-fetching the actor.
it probably makes sense to formally describe this flow in the FEP as well, using normative language – something like “prepend with acct: then resolve via the webfinger endpoint of the host component”? also consider requiring values of the form acct:evanp@example.com instead of evanp@example.com maybe?
A Mastodon implementation expert can double-check this, but it doesn’t appear to me that the example I provided would cause a problem for Mastodon. It supports an array of as:alsoKnownAs URIs and checks for a matching member of that array during Move processing. The issue of Mastodon assigning different semantics to as:alsoKnownAs remains, but I don’t see a technical issue at the moment.
I believe as:alsoKnownAs could also be useful for Objects in general. Webfinger isn’t limited to finding information about people. I can imagine future scenarios where a URN is used for server-independent Object URIs and those can be resolved to local URLs using Webfinger (maybe even a federated Webfinger for that purpose).
Because an ‘acct’ URI enables abstract identification only and not interaction, this specification provides no method for dereferencing an ‘acct’ URI on its own […] Any protocol that uses ‘acct’ URIs is responsible for specifying how an ‘acct’ URI is employed in the context of that protocol (in particular, how it is dereferenced or resolved; see [RFC3986]).
so it probably bears adding at least a one-sentence statement as above. especially if you intend to allow/support the “bare address” without the acct:. (it might also be a good idea to pick one or the other instead of allowing both.)
another minor nitpick: the shorthand term wf:webfinger is slightly ambiguous or unclear, and would probably make more sense as webfingerAcct or acct instead.
