Unify handling of Fediverse claims
Currently, doip.js supports two ways of handling claims on the Fediverse: one for Mastodon, and one for "fediverse", which seems aimed at Pleroma.
The Mastodon handler expects the claim to be in a profile field, and the Fediverse handler expects the claim to be in free profile text (
summary field in the returned AP). Perhaps this is because of an assumption that Pleroma does not support profile fields itself, however it has had backend support since 2019, and frontend support since 2020, so profile fields could be used there as well.
From my brief testing, the following support profile fields:
- Mastodon, has urls that look like
https://example.com/@username, responds to
- Pleroma, has urls that look like
https://example.com/users/username, responds to
- Misskey, has urls that look like
https://example.com/@username, responds to
There is, however, a number of Fediverse software servers which actually seem to have no profile field support, like PeerTube, Pixelfed, Lemmy, or Plume. Some of these have complex URL schemes. For example, Pixelfed profiles usually follow the pattern of
https://example.com/username, but internal AP IDs look like
https://example.com/users/username (coincidentally also Misskey's and Mastodon's internal format)
Therefore, my recommendations would be:
- When expecting an ActivityPub/Fediverse server, send
application/activity+jsonas the Accept header. As far as I can tell, this would make Misskey capable of being handled by the current Mastodon handler.
- Fold the "fediverse" handler into the current "mastodon" handler by making the "mastodon" handler match the current "fediverse" regex as well as the current "mastodon" regex.
- Possibly speculatively send requests with
application/activity+jsonas the Accept header to any unknown URL, and check for the Content-Type in response, and then look either in profile fields or the free-form bio fields, as an agnostic approach
Great suggestions, thanks for the elaborate issue. Need to do some testing but supporting MissKey by just slightly altering the Accept header sounds great.
That being said, our situation wouldn't improve much if we can fold a few AP services into one and then still need to add a few more AP services separately. Perhaps each AP service should be treated distinctively, regardless of how similar some are. Need to think this over.
Re checking multiple locations in the JSON document: good point, this must be added.
Perhaps each AP service should be treated distinctively, regardless of how similar some are.
Surely if different ActivityPub sites can interoperate without special-casing, we can do the same?
I'm not hugely familiar with the technical details of ActivityPub, but couldn't we do something like this:
- use WebFinger to identify the appropriate endpoint, as any fediverse site would do when 'following' a user
- send a request to that endpoint with
- check for a claim in specific fields, including at least
A caveat is that technically WebFinger is not part of the ActivityPub spec, and so AP services are not required to have it. If all you have is a URL, it's harder to tell that it's an ActivityPub URL.
On the other hand, some sort of WebFinger support might be useful in itself, but then that's not exclusive to AP stuff, either.
Ah, I see.
Some random thoughts in no particular order, and without having done any research… :
Maybe as you say WebFinger support would be useful anyway, and even if support were limited to sites which support WebFinger and ActivityPub, that would be more generic Fediverse support than we currently have… I guess?
How does an ActivityPub site which doesn't use WebFinger identify that a particular profile URL belongs to another ActivityPub site? Whatever the mechansim is, can we do the same as a way to generically support all ActivityPub sites?
Would it be useful to start a discussion in https://socialhub.activitypub.rocks/ and see what might be considered the 'idiomatic' way to do what we want to do?
Maybe I should just go and read the ActivityPub spec 😆
So far as I can see from a brief perusal of the spec, a simple request to the profile URL with
Accept: application/ld+json (see below) should be enough to support every ActivityPub site.
But, supporting WebFinger allows use of a different subdomain to host the software while using hte root domain for usernames. So ideally, we would try WebFinger and then fall back to just requesting the profile URL directly (or vice-versa?).
Regarding mime-types, the spec says (emphasis mine):
Servers MAY use HTTP content negotiation as defined in [RFC7231] to select the type of data to return in response to a request, but MUST present the ActivityStreams object representation in response to
application/ld+json; profile="https://www.w3.org/ns/activitystreams", and SHOULD also present the ActivityStreams representation in response to
application/activity+jsonas well. The client MUST specify an Accept header with the
application/ld+json; profile="https://www.w3.org/ns/activitystreams"media type in order to retrieve the activity.
Deleting a branch is permanent. It CANNOT be undone. Continue?