[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.
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).
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.
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 email@example.com as your email address, rather than firstname.lastname@example.org. It lets organizations host their social server separate from their main Web site, but still use email@example.com as the Webfinger address.
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:firstname.lastname@example.org instead of email@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.