Webfinger

[squeevee]

Is there any intent to support Webfinger with this library, since Mastodon uses it? Or is the library strictly ActivityPub-as-advertised?

[jdormit]

Yup, I think WebFinger definitely belongs in the library since it's a de-facto standard for AP discovery. I'm still up in the air about what the API should look like. It could be built into the existing handle() method, in which case callers would need to delegate to handle() when their application receives a JSON-LD request or a webfinger request. That would be the easiest approach for callers, especially if the library provides a way to tell callers when it should handle requests, e.g.

if ( $activitypub->shouldHandle() ) {
    $response = $activitypub->handle();
    $response->send();
}

Or the library could expose a method $activitypub->getWebfingerResponse( $resourceString ) that would return a Response if the passed-in resource string corresponded to an Actor that the library knows about.

The first approach is definitely easier for callers, but it's not very flexible - it locks library users into WebFinger, and it doesn't provide a way for users to customize the WebFinger responses at all (although that could be mitigated by allowing a custom WebFinger function in the config). The second approach is a lot more flexible, but it requires users to explicitly opt into WebFinger and to manually decide when a request is a WebFinger request.

@squeevee, what do you think?

[squeevee]

I'm rather in favor of the second option. I think it's cleaner to separate WebFinger objects from ActivityPub ones. From a calling perspective, it's very logical, even if a little more verbose, if ActivityPub::handle() only handles ActivityPub stuff, and other kinds of requests have their own explicitly named methods. Plus it might reduce internal complexity in the future, especially if stronger data types are used (i.e., #1 (comment))

WebFinger requests can only ever be sent to the URL /.well-known/webfinger (https://tools.ietf.org/html/rfc7033#section-4) so it's trivial to tell it apart from other requests.

[jdormit]

Cool, the second option makes sense to me as well. I'm still in the middle of implementing the core ActivityPub pipeline, but when I get to WebFinger I'll implement as a separate part of the API.

[squeevee]

I've tossed something together (it seemed like low-hanging fruit)

squeevee@1fc4e97

This expects the caller to be able to "canonize" the username from the form [email protected] to the actual ActivityPub id (e.g., https://example.org/@squeevee). I'm not sure if this library should track those associations instead, but if we do then that will make things more complicated.

Wondering what you think before I make a PR

[jdormit]

Yeah, I like this approach. You'll add an ActivityPubConfig field for the Callable that canonizes the Webfinger resource id?

Also, I'm not sure ActivityPub\Controller is the right place for the WebfingerBuilder class - although it's reading a Request and returning a Response it's not really filling the same role as a Symfony controller. I'd prefer a new ActivityPub\Webfinger namespace. Did you mean to return a JsonResponse instead of a JsonRequest?

Nit: could you use array() rather than [] for brackets? I'd like to support PHP 5, since many WordPress installations haven't yet upgraded.

[squeevee]

Will do all that.

If we're delegating to the caller to canonize usernames, then it might also make sense to have the caller responsible for validating / checking for the existence of usernames. In which case, the json builder could be a static function (maybe in the Utils namespace). If it's static that wouldn't work with the callable being set to an ActivityPubConfig field but food for thought?

It's difficult for me to anticipate any more WebFinger functionality being necessary unless at some point in the future this library takes charge of canonizing usernames.

[jdormit]

I think it would make sense for the JSON builder to at least check for the existence of the canonical actor in the database (as it does in the current iteration of your code), which would mean it couldn't be static. I do agree that we probably won't need much more WebFinger functionality beyond this though.