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:
-
This is in layman’s terms the crystal-clear elevator pitch and bullet points of what Solid adds to the existing linked data web
- This is the intuitive roadmap that we follow to bring this to you
- Drilling down on each of the bullet points will lead you progressively to the nitty-gritty details
- This is the process that we follow, and the parties that are involved and their roles and responsibilities.
- 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).
-
Standardization of all of this is our primary concern. This is why Solid exists.
- Our goal is for all this to become a natural part of the future web
- Until web-scale adoption is reached here are the use cases where you can already benefit from this
- 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.
- 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.
-
To help guide us and guide our community of implementers we are building an ecosystem around the standards
- In this ecosystem we make specific technology choices, like JS-based techstack, but the Solid standards are for any techstack
- Here are our reference implementations, here are our example applications and here are our community-driven projects
-
Here’s our community of friends that help us in our quest
- And this is the way to come aboard, where we gladly welcome you, to help the community to be more than just a forum.
- 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 @codenamedmitri also mentions “Inrupt, as well as the Solid community, should join the DID WG!” and Project: Support W3C Verifiable Credentials on Solid.