Friendship and other non-follow relationships

For being a social protocol, I was somewhat surprised to see that there are no FEPs around something as basic as friend relationships or other social relationships (at least, I didn’t find any).

Currently, the only relationship that ActivityPub really defines is the Follow relationship, i.e. the asymmetrical relationship where Alice follows Bob, because Alice would like to see all the activities that Bob produce.

The ActivityStreams vocabulary does talk about relationships in a more general manner, but it is quite vague and this (afaik) doesn’t seem to have translated to a wide usage of this approach. It even talks about how you could model requests of those relationships, i.e. friend requests, via the Offer activity with a Relationship object.

Are there implementations out there that use the ActivityStreams’ (somewhat loose) definition of relationships and relationship requests? I saw Friendica has this page on “Making Friends” and just from the name of Friendica, you’d think they’d have some notion of friends and friend requests. But from that page, I’m not sure how Friendica represents friends or federates those requests. And are there any other implementations out there that have relationships other than followers and requests for those relationships?

Would it make sense to write an FEP describing the approach laid out in the ActivityStreams vocabulary in more detail? I feel that such an FEP should at minimum cover the usual case of friends and friend requests, but ideally should be generic over any kind of relationship you could imagine (or perhaps at least any relationship defined at https://vocab.org/relationship/).

Or would it be more sensible to implement an approach, learn from that and write an FEP later?

4 Likes

Probably better to try some things out to see what works.

AS2 Relationship is a very underdefined approach and AP being more pubsub oriented went with Follow rather than Offer Relationship. I think Friendica and similar just go for “mutual followers” as a substitute for proper modeling of connections?

1 Like

Yea that seems a bit weird to me, since following is completely separate from being friends, if you ask me. I have friends I would want to follow, but I definitely also have friends that I don’t want to follow :sweat_smile:. “Friends” on social media is often used quite liberally to also contain even distant acquaintances.

Would be great if someone who knows more about Friendica could comment on their approach/thought process :slight_smile:.

To give a little bit of context from another implementation, NodeBB implements a follower system like ActivityPub.

Out of the box we don't have the concept of "friend", but if we think of the usage as that of early Facebook, then a "friend" relationship implies a reciprocated follow... similar to a LinkedIn "connection".

In AP-land, that'd be a follow-accept and then a follow-accept from the other direction. Whether this is completely automated or manual is dependent on the implementation, I suppose... although I would clarify that because we're talking about S2S interactions between different softwares, you can basically never guarantee when (or even if) the reciprocated follow will occur.

This is at best a shortcut or substitute, but not a fully qualified semantic representation. I think ideally we shouldn’t mix followership with friendship. You should be able to connect with someone without subscribing to all their activities. Of course, this then means we have to define what “connect with someone” means. What does a connection imply? Access control? Some kind of social graph processing or reasoning (e.g. friend-of-friend)? That part is left open-ended.

Friendica simply follows back when you receive a follow request and you want to make it bidirectional.

With regards to both Facebook and LinkedIn, it’s worth noting that they have both long separated following and friendship (in Facebook’s case) or connection (in LinkedIn’s case). That is, you can be friends on Facebook without following and you can also be connected on LinkedIn without following. So there’s precedent that these things should not be considered equivalent.

Honestly, I don’t think the functionality has to go much further than a simple collection (akin to the followers collection). Friends on Facebook and connections on LinkedIn are used for friend-of-friend or connection-of-connection stuff, but that can be inferred from the collections. Aside from that functionality, I’m not aware of huge implications when it comes to functionality if we consider how it is used on Facebook or LinkedIn.

For instance, I believe you can post things on Facebook that only your friends can see. But that could easily be handled by just using the friends collection in the to or other addressing fields, just as the followers collection is used in those fields today.

I see these relationships as mostly semantic information for users to consume, not so much for any technical functionality. I.e. it is nice to have a list of your friends and/or family and it is nice to be able to see the friends and family of your friends/family. I think that is the primary use case. But anyways, this is getting into the weeds of writing the FEP which I think we agreed we should not do now :sweat_smile:

google+ had “circles”. Google social network failed for reasons, but ‘circles’ itself may be a good idea, also seems compatible with ActivityPub.

Maybe one does not need to guarantee. ‘Circles’ were one-directional.

For example, I create a “Family” circle and add some public music superstar there (Lady Gaga let’s say). In terms of ActivityPub, that would mean I “follow” the superstar in my “Family” circle.

She is in the circle, I will see her public posts, but she won’t see my posts unless she add me back in some of her circles as well (in other words, ‘follow’ me back, manually).

If she has ‘notifications’ enabled, then she will get notified that I followed. But if notifications are disabled, then maybe she will notice me by ‘liking’ some comments I write on public posts and decide to follow back.

In other words, mutual connections were happening naturally through general notifications and various general interactions like commenting on posts etc.

Posts would be addressed (access controlled) to the members of the ‘circle’. One chooses to what circle to post what content.

Friendica, Hubzila, (streams), Forte and similar platforms have something called “connections” which is basically a mutual follow situation.

The reason this exists is that these platforms have private posts.

If you follow someone, you can only see their public posts. If they follow you back, you can also see their private “friends only” posts. This two way follow is a “connection.”

Most fediverse platforms don’t have something like this because they don’t have private posts.

Technically, you can follow in one direction on these platforms, but you would only see their public posts, and not their private “friends only” posts.

The three existing types of relationships in the fediverse are:

  1. Follow (could also be called Subscribe in the case of blogs).
  2. Connection (equivalent to a two way follow).
  3. Join (for private forums and discussion boards. You must be a member to post, which in ActivityPub would be represented as a follow.)

These are primarily used for sending & receiving messages, and in the case of “connections” and “join” are also used for access control.

Considering that some people would only want to share relationship information (as defined in https://vocab.org/relationship/) with trusted people rather than the public, you would want to take that into account.

For example, Friendica, Hubzilla, et. al. will only release private profile information if there is a connection. In other words, if they don’t follow you back, you can’t see their private profile information.