Indicate support for multiple ActivityPub feeds associated with a single webfinger id.

[blaine]

One of the great sadnesses that I have is that webfinger identifiers [in mastodon] are 1:1 with activitypub actors. One of the original goals for webfinger was the ability to have one "social address" that was able to point to many representations of personal facets, and to date, this goal has been elusive.

For example, an individual is likely to have a short, public texts ("tweets" or "toots") account, a blog, a place where they share photos (public and/or private, e.g. pixelfed), a place where they share videos, accounts on reddit or lemmy, reading sharing, fitness feeds (strava etc), private 1:1 or group messaging (whatsapp/signal/rcs/imessage/etc/etc/etc/etc), and so on. Each of those applications have different "social objects" and displaying the ability to subscribe to someone's political tweets from a fediverse-compatible strava clone probably doesn't make sense.

Without the ability to point to multiple activitypub or other feeds, with associated media types, it's a bit of a mess. We can either present the user with a complicated interface to choose between a number of feeds or apply heuristics (brittle by nature) at the point of subscription, but neither of those are good options. Alternatively, we can have distinct account addresses for each activitypub feed (e.g., mastodon@bcook.ca, pixelfed@bcook.ca, and so on), but that means that people are unable to find their contacts across services without knowing up-front all of the valid addresses associated with those contacts (impractical to say the least). Another option would be to revert to URLs, which suffers from both the former issue and ignores the relative success that webfinger addresses have had in the fediverse over URLs.

The real solution, in my mind, and as above is to allow for multiple activitypub links with "media type" attributes associated at the link level.

The current schema is a bit wanting, so some definition work will be required. I'm personally not bothered by formats. I don't think the specifics matter so long as we all agree and adopt a consistent approach. As a possible example:

"links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://mastodon.social/@blaine"
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "media-type": "social/tweets",
      "href": "https://mastodon.social/users/blaine"
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "media-type": "social/photos",
      "href": "https://pixelfed.social/pixelfed.social/blaine"
    },
]

or alternatively, rel=self could be augmented like so: "rel": "self; social/photos" or "rel": "self; messaging".

I enthusiastically encourage others to suggest their own ideas for formats if the abstract idea seems like a good one, but neither of those specific formats seem ideal (they're literally off the top of my head, and I could list a dozen other possible approaches but I'll spare the reader[s] of this issue for now [hi, Evan 😅].

[tesaguri]

I assume you use the term media type to denote some new concept unique to your proposal, but that term traditionally denotes the same concept denoted by the term "MIME type" (which is an older term for the concept), so I'm afraid that your terminology might be confusing.

Also, I'm not sure if it would be a right thing to use such ad-hoc link relation types so often (probably without registering them according to Section 2.1 of RFC 8288?), although you might be able to use extension link relation types instead in this regard.

Incidentally, the report already has a guidance on the handling of multiple links to Activity Streams documents (Section 3.2. See also #5 and mastodon/mastodon#19059 (comment)):

• Check for additional information, such as the presence of properties which may give further hints as to which entry of links is appropriate to follow

Is there any additions that you think the guidance needs? Admittedly, it doesn't differentiate multiple actors with e.g. the Person type, but I suppose the same stands for your proposals (unless I'm missing something.)

[trwnh]

Check for additional information, such as the presence of properties which may give further hints as to which entry of links is appropriate to follow

yeah, this seems enough to me. i'm inclined to close this issue as inactionable, unless you have any proposed action items for the report?

[blaine]

I assume you use the term media type to denote some new concept unique to your proposal, but that term traditionally denotes the same concept denoted by the term "MIME type" (which is an older term for the concept), so I'm afraid that your terminology might be confusing.

Fair; sadly, I think "media type" was coined in a one-dimensional world where file formats described the media ("image/jpeg"), and what I'm getting at is more "medium type" – some combination of the display structure of items in the feed / context of intended use.

The question here is how can sufficient information be communicated such that an ActivityPub client can take a webfinger address and pick the best feed(s) to show to the user? It's a fairly complicated intersection, so some degree of data richness seems beneficial.

Also, I'm not sure if it would be a right thing to use such ad-hoc link relation types so often (probably without registering them according to Section 2.1 of RFC 8288?), although you might be able to use extension link relation types instead in this regard.

Agreed, in principle; caveat that with a desire to encourage innovation and diversity. I'd say it must be possible for feeds to be tagged with arbitrary and potentially non-standard types, but that standard feed types should have standards-backed tokens associated to avoid unnecessary proliferation.

Incidentally, the report already has a guidance on the handling of multiple links to Activity Streams documents (Section 3.2. See also #5 and mastodon/mastodon#19059 (comment)):

• Check for additional information, such as the presence of properties which may give further hints as to which entry of links is appropriate to follow

Is there any additions that you think the guidance needs? Admittedly, it doesn't differentiate multiple actors with e.g. the Person type, but I suppose the same stands for your proposals (unless I'm missing something.)

Aha, I had missed properties in the webfinger rfc (I 'invented' webfinger and wrote the first versions of the spec, but haven't kept up with that state of things in the intervening 15 years 😅). I would say the guidance should provide some examples of disambiguating feed types, and properties does indeed seem to be the way to do that. The current verbiage in Section 3.2 is limited to a single sentence with non-normative behaviour (it's a in a list of three suggestions).

Something like this in the examples and guidance in Section 3.2 to indicate the possibility space would be ideal in my mind:

"links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://mastodon.social/@blaine"
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://mastodon.social/users/blaine",
      "properties": {
          "https://www.w3.org/ns/activitystreams/medium": "social/tweets"
      }
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://pixelfed.social/pixelfed.social/blaine"
      "properties": {
          "https://www.w3.org/ns/activitystreams/medium": "social/photos",
      }
    },
]

(the https://www.w3.org/ns/activitystreams/medium namespace is obviously indicative; I don't know or have strong feelings about what the correct value to use in the guidance would be)

[blaine]

Check for additional information, such as the presence of properties which may give further hints as to which entry of links is appropriate to follow

yeah, this seems enough to me. i'm inclined to close this issue as inactionable, unless you have any proposed action items for the report?

See above. I tried to express my reasoning as clearly as I could, and as best as I can imagine the reason that people haven't done this is because they don't know that they can and that there aren't examples (implementation or otherwise) to support them.

It should be trivial for e.g. Mastodon to implement support for adding an e.g. Pixelfed AS link to a user's webfinger profile. This guidance seems the best place to encourage that sort of thing to happen?

[tesaguri]

I feel like the report should primarily document the current practice in the Fediverse, and proposing a non-obvious new mechanism should be done as a separate Fediverse Enhancement Proposal instead (other than as a Future Enhancement).

That said, I agree that it would be nice to illustrate how Lemmy et al. handles Person and Group actors with a same acct: URI as an example of the guidance (though I'm a little skeptical of their use of the non-standard as:type property as I mentioned in mastodon/mastodon#19059 (comment)).

[trwnh]

Something like this in the examples and guidance in Section 3.2 to indicate the possibility space would be ideal in my mind:

This feels like it's too much detail. IMO it's enough to call it out as a possibility without trying to describe exact mechanisms. The mechanisms themselves are subject to extension work like being described in a FEP or otherwise implemented in a plurality of projects.

I agree that it would be nice to illustrate how Lemmy et al. handles Person and Group actors with a same acct: URI as an example of the guidance

I disagree. There are too many antipatterns and bad practices in the way that this is currently done with Lemmy, so explicitly including it in the report feels like somewhat of an endorsement, i.e. "this is how it could be done" when in fact it shouldn't be done like this. But at the same time, explicitly calling it out as bad practice feels like overstepping the report's scope.

as best as I can imagine the reason that people haven't done this is because they don't know that they can and that there aren't examples (implementation or otherwise) to support them.

I don't think this is the case. Clearly, people know they can do this; it's more that they decided that they shouldn't, at least in most cases. Particularly with respect to the current usage of the self link relation, this generally implies a 1:1 relationship between the subject and the target. Semantically, the way Mastodon uses the self link is to say that the resource acct:someone@mastodon.example is equivalent to / identified by the IRI https://mastodon.example/users/someone when requested with / returning a mediaType of application/activity+json. Per RFC4287:

The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.

This is similar to the usage of JRD aliases and subject, where subject is roughly analogous to rel=canonical and aliases is roughly analogous to rel=self.

In this particular usage case (multiple resources with different purposes), I'd also consider defining a proper link relation instead of relying on the properties of a self link. Imagine something akin to http://webfinger.net/rel/profile-page but specialized to indicate the exact kind of profile being linked to. So you'd have multiple rel-values along the lines of the following:

• http://social.example/rel/photos
• http://social.example/rel/tweets

...and so on. But again, this is pretty out-of-scope for the report. You'd need to specify the link relations in a proper spec somewhere and then propose people use those link relations.

[blaine]

But again, this is pretty out-of-scope for the report. You'd need to specify the link relations in a proper spec somewhere and then propose people use those link relations.

Fair enough. Disappointing, since the whole point of creating webfinger was to enable the use-case I've described. 🤷‍♀️

Non-normative and future speculative uses are covered in Sections 4 and 6, so it doesn't appear from the outside as out of scope. There is also significant text in 3.2 that discourages the use of multiple AS feeds in a profile, despite there being no standards reason to do so other than "Eugen hasn't so far." At a minimum I would recommend deleting the line "Publishers SHOULD include only one such link." in Section 3.2, and probably most of the remaining copy in 3.2 should be moved to Section 6 for the purposes of this report.

I'm reminded why I really don't enjoy doing specification work, despite its importance. My feedback here is that specifications in their early stages should point at possibility for agreement, and create opportunities for implementors to experiment. As the implementations and specifications evolve and gain traction, they can and will be refined.

You're free to disagree, of course. I say all this as someone who values adoption of open technologies at scale over the specifics of the technology itself, and I fully acknowledge that this is a difficult circle to square in the context of standards work. I would only add that by over-fitting to "the people in the room" (i.e., people who enjoy writing specifications), the standards community risks excluding important voices. 💜

[nightpool]

the whole point of creating webfinger was to enable the use-case I've described.

That really has nothing to do with how webfinger is used by the activitypub community. The whole reason webfinger was adopted by Mastodon was to give an unambiguous, 1:1 mapping from plain text "microformat" mentions (e.g. @username@host) to ActivityPub actors. Allowing for multiple activitypub actors to share the same username would completely break that mentions syntax.

Each of those applications have different "social objects" and displaying the ability to subscribe to someone's political tweets from a fediverse-compatible strava clone probably doesn't make sense.

This goes against how ActivityPub was designed. Servers are supposed to be content neutral, and clients can impose their own filtering on the graph. While fragmentation like you mention may be the way people end up going in the future, there are just too many benefits to having all of those social objects collected under a single Actor identity while allowing for individual clients to filter which activities they wish to present based on what they choose to display, rather than having a different identity for each different client you choose to publish from.

[trwnh]

Fair enough. Disappointing, since the whole point of creating webfinger was to enable the use-case I've described. 🤷‍♀️

I don't see why WebFinger can't do this right now; the only issue is that the purpose of the link relation needs to be clarified first. Regarding the language in 3.2 that "Publishers SHOULD include only one such link", this only applies to the self link. Publishers are of course free to include infinitely many links of infinitely many kinds, except in cases where it doesn't make sense semantically. I can rework the language to make this clearer, but the usage of self is constrained to the relationship implied by the definition of self. In the same way that using canonical more than once is inappropriate, or using alternate more than once is appropriate, using self with a given type usually only makes sense when there is one such link.

I reiterate that if the purpose of this issue is to support "multiple activitypub feeds", then you'd either need to specify discrimination by properties or otherwise (and preferredly) specify a rel that has the meaning that you intend. https://social.example/rel/social-photos, https://social.example/rel/social-tweets and so on would all be more appropriate than multiple self-links as described in the report. Relatedly, ActivityPub isn't built on the concept of "feeds" but rather on actors/activities/objects, so there isn't really an "ActivityPub feed" link relation for that reason.

[silverpill]

It seems that the status of this document is not well-defined. The title says "report" and the "Status of This Document" section says "It is not a W3C Standard nor is it on the W3C Standards Track.". Nevertheless, the document contains normative statements. Are SHOULD and MUST words really appropriate here?

Regardless of its status, I think FEP is a better format for proposing improvements.

FEPs are reviewed by the community, and if the idea is sound, it might be implemented by developers. FEPs that see significant adoption could be mentioned in official W3C reports, but untested ideas should never appear in any authoritative document.

[trwnh]

It seems that the status of this document is not well-defined. The title says "report" and the "Status of This Document" section says "It is not a W3C Standard nor is it on the W3C Standards Track.". Nevertheless, the document contains normative statements. Are SHOULD and MUST words really appropriate here?

The status/track is "it's a draft of a Note". Normative language within this Note is intended to describe the "profile" of WebFinger as used in current ActivityPub implementations (i.e., for forward discovery and reverse discovery). The difference between a Note and a Standard is that a Standard is much more weighty; it defines an actual specification rather than just describing technical usage of a current specification (as a Note often does).

[blaine]

@nightpool: I am so much less than interested in being ActivityPub/standards-'splained to it's not even funny. It was worth a shot, I remain disappointed in technologists that don't think about the wider social implications of the work that they're doing, news at 11. Apologies for the less-than politic comments, but there's a very long history of technology fiefdoms overrunning communities and misreading the possibilities offered by the technologies they help create, and some of the comments here feel like another example of that.

I won't hold my breath waiting for the apology for the condescending and dismissive tone, but @evanp mentioned at some point that he'd like to see me back in the standards world, but this ain't it for me. I hope y'all figure out how to communicate to newcomers, because the world would be better for it. Thanks to those who already have, you know who you are. ❤️✌️

[silverpill]

@trwnh Perhaps it would be better to change the title of section 3.2 to "Recommendations for establishing a link between the WebFinger resource and the actor document" ? Or replace "rel MUST be self" with "rel is self".

I can see the benefit of using RFC-2119 in other places, but in 3.2 it sounds too strong.

[silverpill]

Also in section 2.1: "This request MUST returns a JRD"
It can be changed to "This request returns a JRD".

IMO that would be more appropriate for a description of current practices.