Represent bidirectional connections

[evanp]

The "Follow" Activity type lets us model unidirectional connections -- Evan following James means that Evan gets updates of James's activities, but not necessarily vice versa.

Many social networks (Facebook, LinkedIn) have bi-directional connections - one user "requests" friendship from another user, who then "accepts" or "rejects" it. Afterwards, both users get updates of each other's activities.

It would be good to be able to model this schema, since it's pretty common on social networks.

[jasnell]

Let's unpack this. There are actually several distinct activities at work in this scenario.

1. First, one user extends and connection offer to another user. The as:Offer and as:Relationship classes work well here.

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    {"colleagueOf": "http://purl.org/vocab/relationship/colleagueOf"}
  ],
  "@id": "http://example.org/connection-requests/123",
  "@type": "Offer",
  "actor": "acct:evan@example.org",
  "object": {
    "@id": "http://example.org/connections/123",
    "@type": "Relationship",
    "subject": "acct:evan@example.org",
    "relationship": "colleagueOf",
    "object": "acct:james@example.org"
  },
  "target": "acct:james@example.org"
}

1. Once the offer is extended, the target can use as:Accept or as:Reject to indicate their disposition towards the offer.
2. Assuming the offer was accepted, there are two distinct as:Follow activities in which each user follows the other;
3. And there are two distinct as:Add activities in which each user adds the accepted as:Relationship into their respective "connection" collections.

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "Collection",
  "items": [
    {
      "@type": "Accept", 
      "actor": "acct:james@example.org",
      "object": "http://example.org/connection-requests/123"
    },
    {
      "@type": "Follow",
      "actor": "acct:james@example.org",
      "object": "acct:evan@example.org"
    },
    {
      "@type": "Follow",
      "actor": "acct:evan@example.org",
      "object": "acct:james@example.org"
    },
    {
      "@type": "Add", 
      "actor": "acct:james@example.org",
      "object": "http://example.org/connections/123",
      "target": {
        "@type": "Collection",
        "displayName": "James' Connections"
      }
    },
    {
      "@type": "Add", 
      "actor": "acct:evan@example.org",
      "object": "http://example.org/connections/123",
      "target": {
        "@type": "Collection",
        "displayName": "Evan's Connections"
      }
    }
  ]
}

[elf-pavlik]

I see major difference with a way how we verify both sides of given connection within silo and in decentralized network. Given

{
  "@id": "https://evan.example/connections/123",
  "@type": "Relationship",
  "subject": "https://evan.example",
  "relationship": "colleagueOf",
  "object": "https://james.example"
}

One needs a way to verify it from 'the other side', and not consider claim above as valid unless confirmed by something like:

{
  "@id": "https://james.example/network/a98dfuda0a9fj0a",
  "@type": "Relationship",
  "subject": "https://james.example",
  "relationship": "colleagueOf",
  "object": "https://evan.example"
}

Of course we still need a way to verify authorship of claims above. For example with something like rev="author"

{
  "@id": "https://james.example/",
  "@type": "Person",
  "@reverse": {
    "author": [
      "https://james.example/network"
    ]
  }
}

{
  "@id": "https://james.example/network",
  "@type": "Collection",
  "author":  "https://james.example/",
  "items": [
    "https://james.example/network/a98dfuda0a9fj0a"
  ]
}

This comes very relevant to work happening in W3C Credentials CG. Example above works similar to 'hosted credential' while more focus seems to go into 'signed credential' lately. Above scenario you could consider as sort of FriendshipCredential

Also very relevant conversation with @fosterlynn and @ahdinosaur with an example from a platform under development available in hackers4peace/plp-docs#12 (comment)

[elf-pavlik]

I illustrated it in social-vocab repo