Webfinger endpoint

[srosset81]

Although Webfinger is not required by the ActivityPub specification, it is used by all ActivityPub servers.

The /.well-known/webfinger endpoint must be at the root of the identity provider, so it cannot be handled by an ActivityPub agent.

I know that @thhck developed a CSS extension for that, so it would require to activate it by default (it's a very lightweight spec).

[thhck]

Saying that I did a webfinger extension for CSS is a bit of a stretch 😅 ( it was just a simple endpoint returning a webid from a @podname@css-server identifier )

I'd be happy to fully implement it, but I do have some questions:

• how do we define the acct value, ( which I guess would be @podname@solid-server-url )
• how do we define the value of the returned JSON:
  • should the webId be in the aliases or in the links, with rel: profile ? ?
  • then return some value from the webId but formated for the webfinger response ( like idp url ? )
• what are the items that should be returned that are not part of the webId ?

I'm curious @srosset81 how did you implemented it in activityPod

[srosset81]

Hi @thhck
You have an example of a Webfinger endpoint here: https://mastodon.social/.well-known/webfinger?resource=acct:Gargron@mastodon.social
Taken from this Mastodon doc: https://docs.joinmastodon.org/spec/webfinger/

But the only really useful data is the rel: "self": as you can see on the ActivityPods webfinger endpoint: https://mypod.store/.well-known/webfinger?resource=acct:sro@mypod.store

So yes, basically all you need is to return the WebID :)

[thhck]

ah thanks for those example, very helpful !
So if I understand well, in activitypOd you handle everything in the webId ( activitypUb related links etc.. ) and the endpoint serve only to discover the webId url through the webfinger protocol.

Then if I'm not missing anything this implementation should be trivial.. but not very useful on its own

[srosset81]

Yes it is very limited. Basically, it allows to map a user/domain to an URI. It's mostly a convenience, to allow to easily find users or mention them.

[mrkvon]

Per experiment by @angelo-v, if one's pod's storage is at origin (i.e. username.solidserver.example, not solidserver.example/username/), then it's enough to PUT .well-known/webfinger with content-type:application/json at the root of the pod (and domain name).

[jg10-mastodon-social]

My understanding is that webfinger should return a single account, specified using the resource query parameter.
https://swicg.github.io/activitypub-webfinger/#forward-discovery

The approach of PUTting the webfinger document therefore only works if the server hosts a single actor.

However, sending and receiving activities is still possible without a webfinger registration.

[jg10-mastodon-social]

It seems that for follow requests #15, Mastodon tries to resolve the webfinger and rejects the request if webfinger does not point to the actor.

Edit: The webfinger acct is constructed from preferredUsername, which is also mandatory for interaction with Mastodon.
https://github.com/mastodon/mastodon/blob/9d81561bb2440c8fb9a75bd05277120aff346b1e/app/services/activitypub/fetch_remote_actor_service.rb#L33

[jg10-mastodon-social]

A key quote from https://docs.joinmastodon.org/spec/webfinger/

Because Mastodon heavily relies on mentions for addressing other profiles, WebFinger is required for fully interoperating with Mastodon. Users can generally load profiles by searching for the direct HTTPS URI if they know it, or for the username@domain address, but Mastodon’s internal logic depends almost completely on acct: URIs or username@domain representations. Searching for any objects or profiles from an ActivityPub implementation without WebFinger will fail because the author cannot be converted to a user in the local database.