Well, yes and no.
In Solid, there are only two types of files: RDF Resources and binary resources. It is true that, when we’re talking about “binary resources”, Solid doesn’t place any constraints on the data. You can store anything (a video, an image, an audio file, or whatever other file you want to store). However, the main data type that Solid apps should use are RDF Resources, because that’s what other applications will understand.
You’re saying “plaintext”, but RDF resources are not just plain text. Your server may be storing the data in plain text (using Turtle, for example). But that’s just an implementation detail, other servers may be storing data in a database.
Of course, there is nothing stopping you as a developer from storing all the data in non-RDF Resources. Like you did for the chat using JSON, or using encrypted blobs here. But as we already discussed in that other thread, that means it’s very unlikely that other apps will interoperate with your data. Which, in my opinion, defeats the whole purpose of Solid. I you just want a private data vault, I’m sure there are better solution out there.
This where we disagree completely, I think that’s a false dichotomy. The main idea of Solid is to decouple apps from data. Which is totally different to sharing data openly or not.
For example, let’s say I have some sensitive health records stored in my POD. I don’t want to share those with anyone, so they’ll have the most restrictive sharing permissions possible. However, I may want to read that data myself using a different app. What you’re achieving with this encrypted approach is that I’ll only be able to read that encrypted data with apps using your POD provider and your Vault SDK.
–
The reason why I think this is an issue is that, in my opinion, this is misleading. Similar to the concerns I raised about Inrupt’s Data Wallet, if you’re advertising that your service uses Solid and saying things like “Solid is a W3C standard. Your pod uses open formats that any compatible app can read. You’re never trapped with a single vendor.” (taken from your landing page), you can’t add features like this that make data effectively useless outside of your platform. In my opinion, that’s the definition of vendor lock-in.
Even worse, you also say “Because it’s based on an open standard, you can move your pod to any compatible host — or even run your own server — and all your apps keep working.”. But as far as I understand it, this Vault SDK is coupled to the functionality in your provider, right? On top of that, it only works for paid accounts. So if I started using your service, but then I decide to move elsewhere (or stop paying the subscription), all the data created with this Vault SDK would be trapped to your service.