Yes, I see what you mean, and that is a clear diagram. Someone reading it will infer that “app” could also include their app if they implement / integrate solid standards support. It could also say “compliant app”, but not “solid app” or the confusion returns.
Note that I am nit-picking on this, because I think it is crucial to Solid’s widespread adoption. Most times I’ve seen Solid discussed outside of solid community e.g. on Hacker News (not unimportant), it was with a lot of confusion and misunderstandings.
In that light I think “an app operating in the Solid ecosystem” should also be avoided, because now I have the impression that I have to integrate with an entire ecosystem, and build my app around that.
I find the terminology in Encrypted Data Vaults to be much more intuitive.
- Encrypted Data Vault vs. Personal Online Data Storage (“Ah, you mean like Google Drive, ‘Free Cloud Storage for Personal Use’…”). The first is much more descriptive. If you use POD’s then it must be followed with an explanation of the acronym.
- Uses familiar Client + Server terminology and avoids Services and the overloaded term Apps altogether
- Having a Vault it is clear that I could host it on either a Client or a Server
- Storage server vs. POD Provider. A storage server is a universal concept. Is a POD provider a specialized storage server?
I also really like the Core Use Cases section. It is written so that most non-techies can understand
- It also avoids words that can be confusing, like ‘privacy’ and 'encryption. It just says e.g. “only I can see and use the data”. Instead “Prioritize Privacy” is a Design Goal.
- It avoids even ‘personal data’ saying just ‘data’. What is personal data? When does it go from being data to personal data or back? Why would I not store more than personal data in my vault? The word data is sufficient. ‘Personal data’ is open to interpretation and there is much discussion on what is an is not personal (e.g. see GDPR-related discussions).