Why does Solid need a specific social media style Profile spec?

[woutermont]

Continuing on https://github.com/solid/webid-profile/issues/61, where I tried to show why a WebID has nothing to do with the social media conception of a profile, I would like to go further, and suggest that such an idea has no place in a Solid specification.

Per the spec:

The aims of the Solid project are in line with those of the Web itself: empowerment towards an equitable, informed and interconnected society.

An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting.

What this says is that Solid, just like the Web, is about making things more fair, equal, knowledge-based, educated, communal, decentral, secure, privacy-minded etc. It is therefore not surprising that the spec and GC pages often mention 'variability', 'interoperability', 'extensibility', 'loose coupling' and 'protocols', 'mechanisms', 'formats', 'interfaces' etc. What the spec does NOT mention is why Solid would have some intrinsic need to provide people with a very specific way of presenting a social media profile.

All of this should really be unsurprising since, just like the Web, Solid is about providing infrastructure that can be used equally by everyone, for every purpose, without having some applications be raised to a privileged status. Sharing social media data, and displaying that data in social media apps, should therefore not be different from sharing and using other data, i.e. using the default ways of discovery, authorization, and data governance, instead of a priviledged front-row seat in the (Solid) WebID Profile.

[jeff-zucker]

One can argue all one wants about whether a Solid Profile, in the social media sense, should exist. The fact, however is that they do exist.

And I believe they should, exactly because of the privileging you speak about. The basic operation in Solid is to encounter a thing and to find out what kind of thing it is, what it should be called, how it can be further accessed. That is what a Solid Profile does for a Social Agent. That is why it should be privileged.

[woutermont]

One can argue all one wants about whether a Solid Profile, in the social media sense, should exist. The fact, however is that they do exist.

I would continue to argue that they don't. What exists are people placing some social media data in their WebID Profile Document. In and of itself, such practice has nothing to do with Solid: people could do that long before Solid, and would still be able to do so if Solid died a silent death.

The basic operation in Solid is to encounter a thing and to find out what kind of thing it is, what it should be called, how it can be further accessed.

This is simply not true. Please read the original issue again, which clearly states (with referenced quotes) what Solid's aims are. If we then go through your statement step by step:

• "To encounter a thing": this definitely plays a role in Solid, but is not its aim; more specifically, Solid only refers to other mechanisms who have that as a "basic operation" (WebID, later DID, or a more open description).
• "To find out what kind of thing it is": again, this is not Solid-specific, but of importance in a lot of Linked Data fields; for that purpose, we have RDF Types, and RDFS or OWL ontologies.
• "To find out what it should be called": similarly, this is done much wider than Solid alone, using rdfs:label or foaf:name.
• "To find out how it can be further accessed": once more, the WebID spec alone suffices in providing this feature.

A huge part of the Linked Data world relies on the features you describe, and Solid definitely does so too. But this does not mean that Solid itself should specify anything about those mechanisms. If that was the case, every specification would become impossible to read, containing an infinite number of repetitions of the many other specs they build on (including HTTP and TCP).

[jeff-zucker]

Allow me to pose some counter-questions. Solidcommunity.net alone has over 50,000 unique users with "social media style profiles" that are served when someone visits their webID. How does the interop group plan to transition these profiles to something more like what you want profiles to be? Is there a detailed and documented plan developers can follow to transition the many apps which currently edit or present profiles? Is there a detailed and documented plan users can follow to convert systems protected under current practice permissioning rules to the new system? Are there multiple functioning implementations of the interop setup that have been tested in the wild over a period of time?

[woutermont]

Solidcommunity.net alone has over 50,000 unique users with "social media style profiles" that are served when someone visits their webID.

How do you know? Maybe it has over 50,000 accounts, but I know at least a few dozen of users and test accounts that definitely don't use it like that. If privacy wouldn't prevent us from doing so, it would be an interesting reality check to compare them all.

---

But you pose a number of totally justified questions, which I wholeheartedly +1, and for which I have raised https://github.com/solid/data-interoperability-panel/issues/285. However, your demand for compatibility has to meet a counterdemand for future-proof normativity.

One of the main things I try to point out (here as well as in SAI), is that we should tackle these problems together. Another one is that we should tackle these problems as separate, orthogonal mechanisms:

1. [A] A mechanism for apps to discover their own entrypoints, without seeing those of others. [B] A mechanism for apps to discover (via [A]) the data to which they have access.

2. A mechanism for requesting and granting access, compatible with [1], a proposal of which is part of SAI.

3. A recommendation of used mechanisms, i.e. which (technical) entrypoints should be declared in the ID Profile, including [1], [2], authentication mechanisms (e.g. OIDC), LDN, and possibly others. Since these are entrypoints, I do not believe this profile should be Solid-writable.

Within each of these concerns, we can then try to find a way to let existing apps be compatible with these mechanisms. I honestly believe this is possible: to specify the ideal mechanisms, and still remain compatible up till 1.0 or even 2.0 of the specs.

1. [A] has no mirror in WebID-Profile, AFAIK. [B] is done via TypeIndexes. Your issue https://github.com/solid/data-interoperability-panel/issues/247 has some strong ideas to combine these with SAI's DataRegistries, but fails to address the issue raised by @elf-pavlik, that necessitates [A]. I believe compatibility is still possible, however, if we give an actor like the Authorization Agent the temporary role to sync them.

2. I'm not sure in how far ACRs are edited directly by current apps, but such practice would be incompatible with SAI. If a syncing mechanism can be found, that's no problem. Otherwise, user's might have to choose between "old" apps and "new" apps, or use both with a setting that data for the old apps is publicly available.

3. This is in itself not a compatibility issue, as long as restricted to technical entrypoints. As soon as other data (e.g. names and addresses) are added to the ID Profile, this becomes incompatible with the way data is stored/discovered as in [1]. Again, I think this could be solved by having a temporary mechanism where the user can indicate certain types of data as public, which are then synced between the registries and the (extended) profile, as in [1].

I would be utterly delighted if we could move past these why-or-why-not discussions, and work together on the HOW. I might, if I find the time, already work out some larger sketch of this.

[jeff-zucker]

Solidcommunity.net alone has over 50,000 unique users with "social media style profiles" that are served when someone visits their webID.

How do you know?

The administrators provided the number when they had to do some cleanup work. It is 50,000 unique email accounts with accounts on the server , not unique 50,000 accounts on the server, so duplicates are not show.

I know at least a few dozen of users and test accounts that definitely don't use it like that.

A few dozen out of a 50,000 is meaningless.

[jeff-zucker]

[A] A mechanism for apps to discover their own entrypoints, without seeing those of others.

It is only a subset of apps that need or want this. Many apps want other apps to find their entry points and explore their data. If Solid provides an easy way (webid-profile) for apps to find entry points that want to be found and a complex way (SAI) for those that don't, I see no problem. I also believe that there are ways (for example, type registrations in seeAlso files) that could easily provide this feature with a slight modification to the current system.

I believe compatibility is still possible, however, if we give an actor like the Authorization Agent the temporary role to sync them.

That would be great.

A mechanism for requesting and granting access, compatible with [1], a proposal of which is part of SAI.

The granting of access to apps is an important issue but should , I believe be orthogonal to this spec. At the moment there are three entirely different models ( acl:TrustedApp, Inrupt client registration, SAI). I believe this spec should point to documentation for those models and say something along the lines of "apps need to be authorized by one of these methods which may require additional triples in the profile document, see the respective specs for details".

[woutermont]

[@jeff-zucker] Solidcommunity.net alone has over 50,000 unique users with "social media style profiles" that are served when someone visits their webID.

[@woutermont] I know at least a few dozen of users and test accounts that definitely don't use it like that.

[@jeff-zucker] A few dozen out of a 50,000 is meaningless.

If you formulate it like that, maybe, but taking those few dozen as a sample, 95% of solidcommunity.net users do not have such a profile.

---

[@woutermont] [A] A mechanism for apps to discover their own entrypoints, without seeing those of others.

[@jeff-zucker] It is only a subset of apps that need or want this.

Reason enough to provide that feature in a discovery mechanism.

[@jeff-zucker] I also believe that there are ways (for example, type registrations in seeAlso files) that could easily provide this feature with a slight modification to the current system.

A suggestion that has on many occasions been refuted, most eloquently by @elf-pavlik, but you're welcome to convince me of the contrary (e.g. with a PoC).

[@jeff-zucker] Many apps want other apps to find their entry points and explore their data.

I've seen this come back a few times, unsure of what to say about it. Apps, definitely Solid apps, have no data. Users have data, and users have apps, and users may want apps to find some of that data. If a user wants to share data D with apps A and B, both apps will be able to do so; for example, I can store my music in my pod, use one app to play it, one app to edit it, and yet another service to seed it over a torrent net. That does not mean that I want these apps to know of each others existence, let alone about the fact that I also seed anarchist manifestos. It is for such cases that a more encompassing model like SAI is a good basis to start from (and which we hopefully can make compatible with current practices).

[@jeff-zucker] If Solid provides an easy way (webid-profile) for apps to find entry points that want to be found and a complex way (SAI) for those that don't, I see no problem.

The problem is, of course, having those two ways work together. If my music player uses seeAlso files and TypeIndexes, yet my music editor uses SAI, how will they work with the same music files? Neither SAI nor WebID-Profile has an answer to that, yet one will have to be found before the proposals are finished. Only the latter one however, seems to be categorically denying the problem.

[@woutermont] A mechanism for requesting and granting access, compatible with [1], a proposal of which is part of SAI.

[@jeff-zucker] The granting of access to apps is an important issue but should, I believe be orthogonal to this spec.

I agree. Maybe I am wrong, but I was under the impression that part of current practice, and therefore part of the ideas that form this document, was that apps themselves could read and edit ACRs. If that is the case, however, then [A] this document does (implicitly) contain such authorization practices, and [B] this approach is incompatible with the one proposed in SAI, which again increases the need to split up concerns and work together.

[jeff-zucker]

[Edit : Sorry, hit enter before thinking, my response omitted things it should not have] I'll respond to this issue when I have time.

[jeff-zucker]

I'm closing this issue because there is no action proposed in to be acted on. Further discussion about the social aspects of the profile are welcome in a discussion area. The possibilities of collaboration with SAI should go in another discussion, neither is in themselves something we can directly act on. The issues you bring up about security should either be discussions or, if they are actionable as issues on particular sections of the spec.

[woutermont]

Oh, I was rather curious to see your full answer.

I think the opening text contains a clear workable action: it "suggest[s] that [the idea of a profile (directly) containing social info] has no place in a Solid specification." This issue should thus only be closed if that is either accepted or my arguments refuted, upon which the reflection of it should kept or removed from the draft.

I do agree that collaboration with SAI and the question of security can be treated in other issues/discussions.