There is no clarity on the scope of Solid

[aschrijver]

Sorry, this was already posted on a forum (and I learned just now that that is not really the place to expect follow-up). The whole thread is vision-related imho, but I just refer to my comment of today: Is Solid primarily a privacy platform or an app platform.

If there is value in what I say, then I probably need to create more of these issues, as I have been posting them to that forum for some time (thinking it a central community hub) and got no real in-depth response other than from random members.

(PS. No response to me is required anymore, I was just trying to be helpful and improve the Solid movement)

[aschrijver]

When I look at Solid with an outsiders eye - and today I did that again going through the repo setup - I see:

• Yes, a spec
• But mostly a javascript-based techstack

In no way do I get the impression that this is important for the future of the web.

There are 1,000's of JS-flavoured ecosystems. Somewhere you need to make convince that the spec is all-important and will disrupt the web (if that is still the goal). The solidproject.org website also does not do this. You are just one in a million such websites.

In the past I gave more feedback related to this positioning in my forum posts.

[aschrijver]

I have been confused about Solid's positioning for a long while, posting here and onwards and in the vision panel but here is my line of thinking now.

I formulated this elevator pitch:

Solid is two things:

1. A roaming identity that you can use anywhere on the web
2. A means to free your personal data from any internet application

This derived from solidproject.org website. Here I'd say that 1) is already an unnecessary scope expansion, as there are a bunch of other standards bodies working on this. But as long as there is alignment, that's okay. And you could have 2 standards SolidID and SolidPOD.

How I see Solid in light of bullet 2) is as:

• The interface boundary where my personal data is separated from the web.
• Providing the access layer for the outside world.
• Where I can fine-tune what is accessible (and maybe bind that to rules, policies and other logic to automate things).

Is that on the mark or not?

The above solid summary might seem clean, but the whole scope confusion seems to be caused by one precondtion that is missing:

Only precondition is that for wide-scale adoption we need to move to a semantic web based on linked data.

And then people all over the place implementing the well-scoped standard to become solid-compliant.

So maybe the thinking was as follows:

"Rebooting the semantic web would lead to a lot of resistance in tech world, because many have preconceived notions and gut feelings on the usefulness of that undertaking. So then we name that part of the effort the Solid ecosystem."

And a marketing problem was fixed.

[aschrijver]

I refer to the forum to follow rest of the discussion. Too much copy / pasting otherwise.

• https://forum.solidproject.org/t/solid-scope-and-ecosystem/3100

[aschrijver]

Copying here from the forum thread, for completeness:

---

Thank you @james. And thanks too @jeffz such kind of list bring clarity and should be on the For Developers page as feature / vision cards, with a dril-down to specifics and some diagrams clearly showing how it all sticks together.

So my 2 bullet points correspond to your 1) and 3) and then you get 6) as a natural result of that - as I read it - or are there additional chunks of functionality in that filter that are scope extending? I see bullet 2) assigning meaning, as a precondition to Solid, but it is not one that needs an entire semantic web... I could apply Solid in any bounded context where you have that.

Bullet point 4) and 5) are real scope expanders! Both are, to me, nice-to-haves compared with 1), 3). Question is if 4) and 5) are being worked on to the detriment of progress in the 'core features'? And to what extend can I use these features in isolation?

I recommend reading the paper of the 'competing' standards-effort on Encrypted Data Vaults presented at Rebooting the Web of Trust, Prague. It makes a comparison of existing approaches, including Solid, and builds that out to requirements + architecture etc.

Regarding 4) they give this clear description:

"In the case of Solid, NextCloud, and Identity Hubs, end users have the option of installing and running the server portion of the data store on a device they control, or signing up to an already configured instance hosted by a trusted third-party (eg. a commercial provider, affiliated institution, or friend)."

Aha! This insight is not easy to be had in the Solid world, and before that you will be so confused with 'Apps' and all the complexity of 4) and 5) being discussed, that you probably miss it.

I would urge Solid to use different terminology than 'Apps'!

What I would like to see for solidproject.org content strategy to communicate its message is:

1. This is in layman's terms the crystal-clear elevator pitch and bullet points of what Solid adds to the existing linked data web

   1. This is the intuitive roadmap that we follow to bring this to you
   2. Drilling down on each of the bullet points will lead you progressively to the nitty-gritty details
   3. This is the process that we follow, and the parties that are involved and their roles and responsibilities.
   4. We have a commercial, business-driven side, and we are starting to support a more open community-driven side which we want to be closely evolved in the evolution of Solid. (We recognize that until now we spent less attention to the OSS and free software movement, but that will change).

2. Standardization of all of this is our primary concern. This is why Solid exists.

   1. Our goal is for all this to become a natural part of the future web
   2. Until web-scale adoption is reached here are the use cases where you can already benefit from this
   3. Here are the exact interdependencies between our specs and components, and here are the places where our specs are not places and which you should avoid or expect frequent changes.
   4. This is the complete overview of how Solid relates to other initiatives: how they overlap, and how they are complementary, and what our cooperation efforts are.

3. To help guide us and guide our community of implementers we are building an ecosystem around the standards

   1. In this ecosystem we make specific technology choices, like JS-based techstack, but the Solid standards are for any techstack
   2. Here are our reference implementations, here are our example applications and here are our community-driven projects

4. Here's our community of friends that help us in our quest

   1. And this is the way to come aboard, where we gladly welcome you, to help the community to be more than just a forum.
   2. Here are the exciting community plans and we'll leave it to them to guide you through it (community independence).

---

A bit tangential to this topic..

In general I find the approach of RWOT more appealing, because of a) pure focus on standardization without confusing mix of impl/ecosystem building, b) they seem to take a broader perspective than the more of a 'this is how the web should be' approach of Solid, and this reflects well on c) the standards they are creating which I not only find quite exciting (and well documented), they are also closer on the W3C standardization track.

Luckily I got a satisfying answer that Solid is aware and cooperating with RWOT and considering adding support for said standards.

For instance in Proposal: Support Decentralized Identifiers (DIDs) in addition to Web IDs, where @dmitrizagidulin also mentions "Inrupt, as well as the Solid community, should join the DID WG!" and Project: Support W3C Verifiable Credentials on Solid.

[aschrijver]

More on the forum thread: Solid scope and ecosystem (Post)

[aschrijver]

FYI I ended my forum discussion with this:

---

I will finish my discussion on this topic. All I am saying is that Solid is giving all kinds of impressions, depending on your entrypoint, skill level, expertise and background. And that is not a good thing. I am both a tech guy and a product owner, and I could deep-dive the tech until all of this felt natural and not think about it anymore. But all the feedback in this thread I gave from product owner perspective.

In a way I feel real bad to be nit-picking so much about terminology and perceptions of the Solid project, but on the other hand I think most people that are deeply involved here realize too little how the project is perceived by the outside world.

There is so much complex technical work to do, that this has led to a kind of inward gaze, where there is only little outreach to other initiatives. I see that very clearly in e.g. the ActivityPub vs. Solid outreach where the fediverse people are trying to coordinate work and evolve more closely aligned & together.

Imho Solid Project should grab these opportunities, each and every one of them and give maximum follow-up. They are very important to bring the Solid vision across to a broader audience. Now in the fediverse some developers already ditched the JSON-LD compliance of the AP spec and are proponents to go with plain JSON for the entire future fediverse. That would be really bad.

I gave a quick peek at the activity stats of the forum in the last month. About 55 users commented, from whom plus-minus 20-30 can be considered frequent visitors. That is not much for a project with such grand vision (if I take the bigger variant I read about in some Solid articles). Grow this community, folks :blush:

Thanks for all your feedback :pray: