How to handle Webfinger for group discovery

Hi everyone, I’m a contributor to Lemmy, and have recently implemented Webfinger support for the project. That was already hard enough without any proper spec of how Webfinger is used by ActivityPub implementations. Now the problem is, Lemmy is mainly focused on groups (its a reddit alternative), but I am not aware of any other ActivityPub projects that support groups.

So my question is, what is the best way to handle Webfinger for groups? Webfinger URLs for user accounts look like this:

https://radical.town/.well-known/webfinger?resource=acct:felix@radical.town

The easiest option that will most likely be supported by all existing projects is to use the same URL format for groups. But that will result in problems as soon as we also make users discoverable over webfinger, as users and groups with the same name will collide.

So I guess the next best option is to replace acct: with something else, like group:, like this:

https://radical.town/.well-known/webfinger?resource=group:main@dev.lemmy.ml

Is there already some existing de-facto standard for this, or any other suggestion that would make compatiblity with other projects easier?

what would be the purpose of implementing webfinger for groups? what do you gain over, e.g., a URI?

As far as I know, webfinger is required to support eg discovery through the Mastodon search, so that something like !main@dev.lemmy.ml can be turned into the actual URI that is used for ActivityPub. Sure we could always use the URI, but that would not be consistent with the functionality for discovering users, and also more complicated for end users.

1 Like

this was just merged into mainline Mastodon


thought I would pass this info here as it seems relevant

I actually saw this PR before, but it doesnt include anything about webfinger.

This post was flagged by the community and is temporarily hidden.

I’m planning to have groups in Smithereen, but thought they shouldn’t be any different from users on webfinger level, it’s just that the ActivityPub object that you’d fetch would be Group instead of Person :thinking:

It makes sense to do it as acct: because groups and users share the username namespace (for how I see it, anyway). You can’t have both a user and a group with the same username on the same instance.

It also makes sense to do it as group: because I’m going to store users and groups in separate tables in my database. This way I’ll know which one to select from, and whoever is sending the request can be sure that looking up a user won’t unexpectedly return a group and vice versa.

1 Like

Well in Lemmy, users and groups are completely seperate, so you can have a group and a user with the same name of test. I also dont see anything in the activitypub spec that would prohibit this.

Can you post a link to your project? Search didnt bring anything up.

I haven’t published anything yet because it’s currently too far from being useful, and I haven’t even started implementing groups so most of this is theoretical. There is a live instance I mostly use for testing that successfully federates with the existing microblogging software.

I’ve been considering this question too for Drupal, where as well as users there can be groups through use of plugins like the Groups module.

Options I’ve come up with are:

  • Prevent name collisions. User and group names are globally unique. Probably not an option in many cases.
  • Allow groups and users to have the same name, but assign an alias in the case of collisions. For example if a user is created with the name “example” on a site where there is already an “example” group, the user is assigned the alias “example-1” which leads to the handle @example-1@somedomain.org.
  • For handles, use a convention where a string is appended to all group handles. A user “example” is @example@somedomain.org while a group “example” is something like @example-group@somedomain.org.

option 3 is probably the most transparent and consistent way to handle things, i think? but also, if you want to avoid namespace collisions then it does make sense to have the URI handle this. Perhaps something like acct:group: as a subset of acct:?

the thing you will have to keep in mind is that mastodon et al expect acct:username@domain, but it is your decision whether you want to force this compatibility or not. if you do, then option 3 will work.

the thing you will have to keep in mind is that mastodon et al expect acct:username@domain , but it is your decision whether you want to force this compatibility or not

Yeah, good point. The workarounds I suggested above are going to cause more problems than they solve.

It seems to come down to the non-ActivityPub convention of a handle in the form @actorname@domain.name, rather than the AP id URI. @actorname@domain.name assumes that all actors are users, and so can be looked up (again, by convention, using Webfinger) using the acct schema, which as the acct draft makes explicit is:

a way to identify a user’s account at a service provider

And therefore limited, in most cases, to Person actors. (Sure, a Group could be a user on a site, but most often that’s not going to be the case.)

Yes, we could mess with the @actorname@domain.name format, injecting a schema in there somewhere (@acct:actorname@domain.name), but (a) that’s not supported anywhere and (b) it pretty much defeats the original reason for the @actorname@domain.name format and corresponding Webfinger workaround–that it’s considered intuitive.

So probably we’re left with:

  • For all actor types, the id URI works. Group actors use the id, not the @actorname@domain.name format, for their handle. Webfinger doesn’t come into play.
  • For Person actor types only, and where the Person represents a user with an account on the site, @actorname@domain.name is a secondary, alternate handle format, but one that isn’t guaranteed to be supported by all ActivityPub implementations.

Another thing to consider: Webfinger in Mastodon is used primarily to allow mentions. Is your project going to use mentions of groups? If not, acct: lookup isn’t necessary – you can use the HTTPS URL, either transparently proxied/routed to the ID if the proper Accept header is provided, or you can still use Webfinger but with https: instead.

There’s nothing limiting acct: to Persons instead of Groups – what it represents in Mastodon’s expectations is a single shared namespace for actors according to a certain domain.

Still, I don’t understand why would any of you want to make group and user aliases be different namespaces and so allow there to be a user and a group with the same alias on the same instance. This would be very confusing UX.

1 Like