I have to admit lately I’ve not taken the time to check out other people’s libraries properly. I’m sure we can benefit a lot from sharing our knowledge and code. With that in mind I thought I’d put out feelers for settling on a shared Webfinger implementation - whether that be an existing one or something we come up with. If nothing else this exercise could get us talking with each other more, which is no bad thing.
I picked webfinger because it’s not core ActivityPub and it has potential use for other authors too - plus a higher chance of an existing implementation we can use/adapt.
I wonder if the other node project authors would like to tell everyone a little about their implementation, whether it’s a dependency or home brewed?
In the case of my library, I’ve written a fairly naïve implementation that does little more than look up an actor and return the most basic json template with a link to their profile.
Regarding discovering the Authenticated Actor’s profile I think that we should use “WhoAmI” endpoint, provided by a server during authentication, and not any webfinger method.
We had the discussion on this, it’s implemented in Pleroma, see here and below: https://github.com/andstatus/andstatus/issues/499#issuecomment-459088285
The topic you’re linking to talks about C2S - I take it webfinger is still required for most S2S implementations? In which case I think a common webfinger library still makes sense.
@birdsofpraise Agree, Webfinger protocol may be used on a client side also to discover unknown Actor’s profile. E.g. when a User types the Actor’s URI (Webfinger ID) manually…
I’ve been having a look at a few node AP projects and how they handle webfinger. I think there’s subtle differences but it might make sense to create a connect library for responding to webfinger requests, which can be used with express, koa, and node’s native http server without much pain.
The library could handle parsing the query, check the hostname, 404 responses, setting the correct headers, writing the response, etc etc. An example API might look like this:
const webfingerMiddleware = webfinger(
// The first argument looks up the user and returns the links. Can return the user's url for a shortcut.
async username => {
const user = await myApi.lookupUser(username);
if(!user) { return null; } // Triggers the 404 case
return user.href;
},
{
// Options object allows for more control, like using a custom regex
matcher: /^acct:[@~]?([^@]+)@(.+)$/
}
);
@datatitian so far I think your library is the only one I’ve found that uses webfinger with express. What do you think of this idea? I notice your library splits webfinger requests into three - request parsing, 404 handling, and response generation. I think this connect middleware could handle all of these for most use cases without any extra configuration than I’ve shown above.
The only reservation I have here is that a webfinger specific library might be too small/specific to make it a library of its own. But the payoff of new AP implementors not having to read up on webfinger could be worth it?
Revisiting this topic, I recently decided to start working on an ActivityPub-integrated site again, and I’ve released the code I’m using for webfinger as an npm library:
I won’t be creating a framework but as I go I’ll try to release smaller AP-related packages that might be reusable in other people’s projects.
Yes, the AP Developer Resources watchlist, and I would’ve added but couldn’t find the code repo. Maybe it is private? OSS is requirement for inclusion.