Mutuals collection

[evanp]

Determining whether two people are mutual connections is tedious. This collection shows who a person both follows and is followed by; the intersection of followers and following.

[tesaguri]

I like the idea. But the question is, which type of objects should the collection have?

In order to make the friendships verifiable by third-party servers, I think exposing the Follow activities would be nice. But of which direction (activities made by the actor themselves or by their followers) should the Follow activities be? I think you won't need to verify the activities if the owner of the activity and of the collection is the same, so having only Follow activities made by the actor's followers might be fine.

But making the collection contain activities instead of actors might make it unsuitable for audience targeting, because "cc": <collection of activities> doesn't quite make sense. (I guess that's why the followers collection isn't a collection of activities?)

[nightpool]

What's the user story here? I feel like having an additional Collection to expose this type of information doesn't necessarily solve the most common user stories I see around this type of issue on e.g. Twitter or Tumblr. I feel like the most common usage of this type of data is to annotate Actor profiles and Activities with information about whether you're following a user & whether they're following you. For example, Tumblr annotates activity items with "Mutuals" when you're both following and followed by a given user:

and twitter shows this information separately when viewing a user's profile:

but doesn't have a special term for "both following and followed by". I think this would be more cleanly solved by exposing following & followed-by metadata on Actor profiles somewhere in the C2S API, which would give a lot more flexibility and require less up front work on the client's end

[TallTed]

To my mind, follow is distinct from like, or friend, or coworker, or family, etc.

Mutual or complementary (e.g., employeeOf and employs) listing quickly leads one to consider inference of undeclared but clearly described relationships.

Other users listing themselves as employees of the same company as user_A might be suggested to user_A (and vice versa) as connections they might want to declare... and some users might want to mute all such suggestions, in either or both directions, or suggestions regarding certain people (such as ex-romantic partners) or companies (such as former employers, or companies whose business practices are anathema to user_A)....

It's vital to support blocking and/or "make me invisible to" user_x, to accommodate situations which might be addressed with restraining orders, in 4D-space — whether or not such restraining order is in place.

There are related complex considerations. This may not make implementation of client applications easier ... but it must be taken into consideration.

[trwnh]

i think having better support for arbitrary relationships is probably the real problem here -- the semantic meaning of "friend" is going to differ greatly, and even when defined narrowly as "mutual" it is still probably not something that deserves its own collection / special collection. it might make sense to expose a collection that is managed by the actor, where the items in that collection are implied objects of the semantic triple -- so for example, i might Add someone to my friends collection, as a way to imply that <a> ex:hasFriendshipWith <b>. in UX terms, this could be similar to mastodon's "featured accounts" or "endorsed profiles" feature.

another thing that could make sense is a mutuals collection that is dynamically calculated based on a query of actors that are items of both following and followers:

PREFIX as: <https://www.w3.org/ns/activitystreams#>

SELECT ?actor
WHERE
{
  <i> as:followers/as:items ?actor .
  <i> as:following/as:items ?actor .
}

(the query is probably not 100% correct because of weird interactions between RDF and the AS2 Collection model, but it gets the point across...)

this is in theory something the client can do if they are so inclined, albeit rather inefficiently -- fetch/page/cache each collection, then calculate their intersection locally. but the server could provide this collection via a mutuals property, as an ahead-of-time optimization... again, assuming that there is a compelling user story here for obtaining that information or for making it generally available. which i'm still not convinced there is such a user story.

[evanp]

In order to make the friendships verifiable by third-party servers, I think exposing the Follow activities would be nice.

I think if it's defined as the intersection between followers and following, then it should contain the same type of object as those collections, namely, the actors involved.

[evanp]

What's the user story here?

The first is for the actor themselves to see who their mutual follows are.

The second is to make the collection addressable; it's a more trusted version of having a followers-only post.

[evanp]

another thing that could make sense is a mutuals collection that is dynamically calculated based on a query of actors that are items of both following and followers:

So, I like the idea of having a SPARQL query endpoint, maybe as one of the endpoints elements?

I'm going to see if there are enough social APIs with a mutuals-like endpoint that it makes sense for us to have our own. I know I would use this a lot, but I feel like adding the needs-fep tag means we think we actually need this for ActivityPub. So I'm willing to hold it to a higher standard.

[tesaguri]

A general SPARQL endpoint would be too much of a burden for LD-unaware implementations (which I think ActivityPub wants to support) and I doubt if there is a compelling user story that justifies the burden either (although an optional endpoints member for LD-aware publishers might be nice given that privacy considerations are properly addressed). Also, the SPARQL query wouldn't work for addressing purpose (at least trivially).

A more moderate (but more general than a special mutuals collection) alternative I come up is set operations for collections, like { "type": "Collection", "ex:intersectionOf": ["actor/following", "actor/followers"] } (like owl:intersectionOf, but for as:Collection), which I think can be mapped to SQL queries (if the server knows the operand collections) and is applicable to addressing.

[trwnh]

Also, the SPARQL query wouldn't work for addressing purpose (at least trivially).

This is the one reason I can think of for why a Collection is preferable or needed, but also for addressing purposes, it could be any normal Collection without a property pointing to some special collection. Making a special collection for addressing purposes is something that needs to be handled carefully, especially as it interacts with sharedInbox -- the existing followers collection being used in sharedInbox scenarios has led to an unfortunate requirement for remote servers to be aware of the contents of your followers collection, at least in part... and that means a state machine just waiting to be broken, with potentially disastrous consequences if or when state drifts out of sync.

With that said, and putting sharedInbox aside for now and focusing purely on the existence of a mutualFollowers or mutualFollowing property, I think it could be useful as a sort of server-side pre-calculated collection, but it's not immediately clear how useful it would be. Basically, the advantage you get is that for addressing purposes, you don't have to manage the collection yourself via Add and Remove (as you would have to do with a normal collection).

a compelling user story that justifies the burden [of SPARQL for LD-unaware implementations]

SPARQL might be a bit "heavy" conceptually, but I think any querying language would be similarly heavy. Taking out LD awareness from your query language, you don't actually reduce the burden that much, and you instead lose the ability to deal with extensions.

Still, we have the option of providing properties pointing to "pre-generated query results", so to speak. I'm just concerned that there might be a proliferation of such properties with one for every use-case under the sun. Overall complexity in the ecosystem would rise if this were to become the case.