In FEP-ef61 I use aliases property because all URIs listed under it must resolve to the same object. alsoKnownAs is not suitable because it usually contains pointers to different objects.
alsoKnownAs might work in your case, I don’t see a technical issue either, but I think the relation between acct: URI and actor ID is closer to the relation described in FEP-ef61, than to the relation between object and target in Move activity.
I fully agree. Suggestions are welcome!
if they wouldn’t be http you might be right.
that’s possible today. Helped by redirects.
$ curl -L 'https://mro.name/.well-known/webfinger?resource=acct:social@mro.name'
Allow me to refer once again to the Motivation section of the FEP.
This discovery is unidirectional and can cross domain boundaries. This allows potentially misleading or harmful use of WebFinger to identify actors on the network without their consent. For example, the owner of idiot.example could create a Webfinger address pompous@idiot.example that points to https://activitypub.example/users/evan.
In addition, ActivityPub servers that display actors’ Webfinger addresses in their UIs need a reliable way to know which Webfinger is preferred for a given actor ID.
To solve this problem, [Mastodon][Mastodon] constructs a canonical Webfinger address for an actor by extracting the preferredUsername from the actor’s profile, and prepending it to the domain name of the actor’s identity URL. It then does a Webfinger lookup on that address, and if the actor URL returned matches the identity URL, it uses that Webfinger address.
So, I’m able to look up your Webfinger ID fine:
But Mastodon canonicalizes it to the digitalcourage one:
The FEP in question is for a mechanism to tell Mastodon, and others, what webfinger id you prefer.
First, preferredUsername is not a required property for an ActivityPub actor.
How does the proposal deals with this issue? The proposed property looks no different from preferredUsername in that both the properties are optional.
ActivityPub mandates the use of the id property unless the object is transient (which I think won’t be the case for actor objects) so I wonder if we can use it as the query target of the WebFinger resources, if an ecosystem churn is even worth. But I think this approach would still have a problem that it couldn’t be used for URIs that have no host part like did: URIs, which the proposal is able to solve.
Second, it becomes inconvenient to use subdomains or alternate domains for actor URLs. If the original WebFinger is
evan@organization.example, and the ActivityPub URL ishttps://social.organization.example/evan, the Webfinger will be canonicalized to the longerevan@social.organization.example.
The acct:evan@social.organization.example URI can be canonicalized to acct:evan@organization.example by making the WebFinger resource for the former URI return a JRD with its subject member being the latter URI, which is allowed by Section 4.4.1 of RFC 7033 (WebFinger) as a means to express URIs in canonical form and that is how Mastodon handles canonicalization of acct: URIs (reference).
Admittedly, one could argue that it’s “inconvenient” as it involves multiple WebFinger reources across the domains (though I think it’s natural for the application server at social.organization.example to implement a WebFinger resource endpoint, to which the host of the canonical JRD subject organization.example can simply redirect back), but I believe it would be nice to note that this is not impossible, at least.
Well, I’ve reached the reply limit so I’m going to edit this post instead of replying to relevant posts.
Unfortunately, the WebFinger RFC isn’t clear about the canonicalization process of JRD subjects. While the spec says that “The “subject” value returned by a WebFinger resource MAY differ from the value of the “resource” parameter used in the client’s request” in Section 4.4.1 as I mentioned earlier, it doesn’t specify any requirements on client’s behavior in that case.
Mastodon retries a WebFinger request against the new subject when the returned JRD subject value differs from the resource parameter value of the request. This seems to be a commonsensical precaution against consistency/security issues, especially in case of a cross-domain canonicalization, but even the Security Considerations section of the spec (Section 9.4 in particular) doesn’t mention any verification mechanisms like that.
That being said, I suppose the specification of that process would deserve a separate FEP (or perhaps an addition to FEP-4adb (Dereferencing identifiers with webfinger)).
+1 for the name acct, given that the proposed property is only intended for the userpart and host pairs, because WebFinger is a discovery mechanism for information of arbitrary URIs, not limited to acct: URIs. Mastodon uses the same term for something similar in their client API (the acct attribute of the Account entity).
For the same reason, the terminology of “Webfinger address” introduced by the proposal to refer to “an email-address-like identity in the form user@activitypub.example” doesn’t sound quite right to me. The protocol doesn’t define a syntax like user@activitypub.example without the acct: scheme, either.
this is generally good practice and is sometimes done but is a bit orthogonal to the issue of deriving a webfinger address from an actor document. although
this is indeed “enough” in most cases… provided that the canonical subject is an acct: uri. it is possible to imagine a system in which for example an https uri is the subject and an acct uri is instead stuffed into aliases (though webfinger could resolve both equivalently).
i agree with this point but i think a bigger reason to move away from using preferredUsername for constructing webfinger addresses is that it frees up the property for being used as an actual “preferred username” a la IRC. also, having an explicit property is simpler / more useful / unambiguous.
How does the proposal deals with this issue?
Not particularly well! I more wanted to point out that constructing a Webfinger address from an actor is not actually easy to do.
For the subject trick, thanks for the information! I will update. I think it’s still a bad idea to construct Webfinger addresses from preferredUsername and the Actor ID server part, and much clearer to just have an explicit value. But it’s nice to know there’s another way around it.
For the terminology: As one of the credited participants in making the RFC (look me up in the credits!), I can tell you what the intent was. A Webfinger address is the email-like address. The acct: was added to make it URLish, for systems that need URLs. It’s a necessary evil for certain situations, but the right way to show Webfinger addresses in most cases is without the prefix.
In the FEP, I said you SHOULD use the user@domain format. Because there are a lot of people who insist on using acct: regardless, I said you MAY use that format instead. That should reduce compatibility issues; clients will need to support both, but the preference is to use the bare format.
The ID used here for the Actor ID is exactly what shows up as the actor’s id property: https://digitalcourage.social/users/mro.
I’m a bit late to the game, but I wanted to give a big +1 here. Bridges like https://fed.brid.gy/ have exactly the problem that @eprodrom described in the motivation for this FEP, and as a result, they’ve struggled to present consistent Webfinger handles for bridged users for many years.
As an example, my web site https://snarfed.org/ ‘s bridged fediverse handle is usually @snarfed.org@snarfed.org, but on a minority of servers, it’s @snarfed.org@fed.brid.gy instead, solely because its AP actor id https://fed.brid.gy/snarfed.org is on that domain. Not ideal. I had to dumpster dive through various servers’ issues and code to debug that years ago, along with preferredUsername and other ad hoc behavior. This would have helped a ton. (See Can't reply to Mastodon, public key required? · Issue #73 · snarfed/bridgy-fed · GitHub and other related issues there.)
If omitting acct: is an option, I advocate for the string ‘rfc7565’ in either property name or the namespace to be self-documenting and explicit about the semantics.
Implementing this FEP for my toy server because it seems like common sense. I’d like to propose a slight modification, or at least ask for clarification.
- If provided, the JRD link data for the Webfinger address in the
webfingerproperty MUST link directly to the actor URL verbatim, without redirects or aliases.
I have seen @eprodrom’s sample JSON docs in this thread, and I think this line of specification is meant to refer to the link object in the links array where rel="self". The webfinger JRD should be permitted to return additional links in the links array that are not the actor doc.
Is my understanding correct?
i imagine this can be left somewhat open-ended, but yes, the current practice by mastodon et al is to use a self link of type application/activity+json (or possibly application/ld+json; profile="https://www.w3.org/ns/activitystreams" would be a better fit). if i were to be pedantic, i could argue that we should use a different link relation like alternate instead, but that ship has probably sailed. so it probably would make sense to add this language denoting the self link directly to the FEP.
I would like to note webfinger isn’t restricted to acct: URLs. It can handle any URI.
Use case being, actors that don’t have a username, e.g., groups, temporary anonymous actors, and social networks that use IDs instead of usernames.
The new webfinger property should be able to process https://gimli.laxla.quest/guild/1727 (anonymous group member), https://tech.lgbt/@laxla (profile URL), and https://gimli.laxla.quest#gaming (actor for popular posts in tag).
The new webfinger property should be able to process
https://gimli.laxla.quest/guild/1727(anonymous group member),https://tech.lgbt/@laxla(profile URL), andhttps://gimli.laxla.quest#gaming(actor for popular posts in tag).
No, it should not. Only user@domain. There is no reason that someone would prefer using one of these complicated https URLs as their user ID to the actor ID they already have. If someone would like to set up a way to do that, they can do it in another FEP.
What about actors that aren’t user profiles? Take the tag example. There’s no way to assign a username of the form acct:username@domain to a tag, as anyone can create a tag named the same as a profile. How do you handle these collisions then? Don’t get the logic behind this limitation.
For actors that aren’t user profiles, the HTTPS id is all you need. Although I suppose you could use tag: URIs for whatever reason?
I know in the Fediverse we often use “Webfinger ID” to refer to the user@domain form, but strictly the spec is about looking up metadata for any URI that can be bound to a domain, so I don’t think its good terminology here.
–
I think several people (including myself) have at different times suggested using xrd:Alias for this - as I suggested then, and still suggest now:
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"xrd": "http://docs.oasis-open.org/ns/xri/xrd-1.0#",
"aliases": {
"@id": "xrd:Alias",
"@type": "@id",
"@container": "@list"
},
}
],
"id": "https://social.example.com/user/bob",
"aliases": ["acct:bob@example.com"]
}
(this continues the long tradition of RDF syntaxes stealing directly from their XML cousins)
and the producing implementation would sort aliases in order of preference - so, basically, if you’re looking for the user@domain form of a user, you look for the first acct: URI in user
There are some nice advantages to this:
Defining a dedicated “webfinger” field for this purpose seems strictly less capable.
Minor nitpick, but is there a particular reason to use "@container": "@list" instead of @set? I think the latter is more common if ordering is not relevant.
I would expect the ordering of aliases indicate a preference for displaying them. So if somebody has
"aliases": ["acct:bobette@example.com", "acct:bob@example.com"]
in their account, it indicates that they prefer to be referenced by @bobette@example.com in e.g. mentions or when displaying a post.
Yes, the reason for making it a list was to indicate declining order of preference