Unify handling of Fediverse claims #13

Open
opened 1 year ago by DeeUnderscore · 6 comments

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.

Situation

From my brief testing, the following support profile fields:

  • Mastodon, has urls that look like https://example.com/@username, responds to Accept:application/json
  • Pleroma, has urls that look like https://example.com/users/username, responds to Accept:application/json
  • Misskey, has urls that look like https://example.com/@username, responds to Accept:application/activity+json

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)

Suggestions

Therefore, my recommendations would be:

  • When expecting an ActivityPub/Fediverse server, send application/activity+json as 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+json as 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
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. ## Situation From my brief testing, the following support profile fields: * Mastodon, has urls that look like `https://example.com/@username`, responds to `Accept:application/json` * Pleroma, has urls that look like `https://example.com/users/username`, responds to `Accept:application/json` * Misskey, has urls that look like `https://example.com/@username`, responds to `Accept:application/activity+json` 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) ## Suggestions Therefore, my recommendations would be: * When expecting an ActivityPub/Fediverse server, send `application/activity+json` as 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+json` as 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
Owner

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.

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 Accept: application/activity+json
  • check for a claim in specific fields, including at least attatchment.value and summary
> 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 `Accept: application/activity+json` - check for a claim in specific fields, including at least `attatchment.value` and `summary`

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.

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 😆

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+json as 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.

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+json` as 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.**
yarmo added the
enhancement
label 2 months ago
Owner

I think this PR would solve the issue: #27

I think this PR would solve the issue: https://codeberg.org/keyoxide/doipjs/pulls/27
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: keyoxide/doipjs#13
Loading…
There is no content yet.