A mechanism for showing additional profile information to selected audiences

[evanp]

By default, profile information in the actor object is public. for sensitive information, like dating preferences, or medical history people will want to only reveal that profile information to selected audiences: their followers, their close, friends, members of a group, etc.

We should have a mechanism to include additional profile information that is only readable by a selected audience.

[TallTed]

I submit that the default behavior is problematic. Rather, the default should be that all info is private, and each data point therein should be revealed only by explicit user choice which should include to whom (individual, explicit group of listed individuals, implicit group of individuals with specified value(s) of specified attribute(s), etc.).

It's almost(?) always preferable to accidentally conceal more than what was intended, which is usually easily fixed, than it is to leak sensitive data, which is too often functionally impossible to retract.

[evanp]

One option is to have a property of the actor profile that provides a collection of additional profile data objects.

{
   "@context": {
       "https://www.w3.org/ns/activitystreams",
       "profiles": "@id",
     },
   "type": "Person",
   "id": "https://social.example/user/123",
   "to": "as:Public",
   "name": "Evan Prodromou",
   "summary": "A human person",
   "profiles": [
        {
           "type": "Profile",
           "id": "https://social.example/user/123/dating-info",
           "describes": "https://social.example/user/123",
           "to": {"type": "Collection", "id": "https://social.example/user/123/matches", "name": "Evan's dating matches"}
        },
        {
           "type": "Profile",
           "id": "https://social.example/user/123/resume",
           "describes": "https://social.example/user/123",
           "to": {"type": "Collection", "id": "https://social.example/user/123/potentialEmployers", "name": "Evan's job prospects"}
        }
    ]
}

This covers the problem of access well, but any properties of those extra objects are properties of themselves, not the actor. We need to make it clear that extra profile data also applies to the subject.

[evanp]

@thisismissem notes that the alternativeProfiles collection could be filtered by authorization by the server, as we do for filtered collections.

[nightpool]

This feels like it needs a little bit more fleshing out on the user story/research side—what major social media platforms have this type of affordance? How frequently is it used? I can only think of Facebook off the top of my head, and the usage rate is very low. It feels like a pretty marginal to me—maybe only for a birthdate or similar. Does Twitter support hiding your birthdate? I guess LinkedIn also has extensive access controls, but that's a little different because it's about employment history.

On the UX side, it feels like it's going to be important to distinguish between "doesn't support this type of data or hasn't chosen to share it" and "supports this data but you don't have access"—when you look at a LinkedIn profile, it's clear what the expected fields are and which fields are restricted. I like the profiles suggestion for that reason since you could have an entry for the profile with a type indicating which type of profile it is (birthday, location, etc) but then not have any data in it.

[TallTed]

OpenLink Data Spaces offers such access control for every element of a user profile. Basic permissions are "public" (anyone can see) and "private" (only the user can see), but it is possible to jigger things such that any user-defined group (people who mutually describe themselves as family/relatives; or mutually describe as being friends of each other; or who all describe themselves as employees of company_x; or who are listed as employees by company_x; etc.) can be set as permitted to see. Of course, seeing is only one aspect. Full CRUD functions are available for all data involved, and complex ACLs can be set up, including ABAC (Attribute-Based Access Control) when running Virtuoso Enterprise/Commercial Edition (VEE). (ABAC is not supported by the Virtuoso Open Source (VOS).)

Does this count as a "major social media platform" today? Probably not, but it's difficult to say with certainty, given that VOS and ODS are freely deployable.

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/following-process-in-c2s-s2s-servers/4488/15