I do not mean to come here as a skeptic, don’t take me wrong as I absolutely love the principles of the semantic web and the purpose of Solid, but I feel that there are specific concerns that, if solved, would make the platform more approachable and, indeed, feel more “solid”.
First of all, having your own data Pod and full control over your data is an important principle, yet so far the easiest option for users is to use another service, so whereas before there could only be one way the data could be compromised (e.g. Google), now there are two ways (Google and the Pod provider) someone could access the data without permission. You could buy your own server, but that could be attacked. You could store the data on your hard-drive, but I am not sure how well that could work if you don’t have a public IP address, and of course the data becomes offline when you turn off your computer.
This is where the three technologies mentioned come into play, as taking a similar approach would, even from just a single one of them, greatly increase the state of things in my eyes.
Tor onion services
Without the need for any central authority, an onion service can be accessed safely and anonymously via the Tor network. You don’t need a certificate authority since nobody else can run a service on the same “domain” by design, you don’t need Cloudflare as Tor already hides the real IP address behind its layers, the dynamics of the Tor network make several attacks harder, there is no need to rely on DNS to identify the server, and you can run it on any machine connected to the Internet, even behind NAT.
To me, this seems like the way to host and expose anything, without having any fear the endpoint could be taken down or blocked in any way. In a certain sense, this is just a matter of implementation, since Tor URIs are a subset of normal HTTP URIs, but encouraging the use of Tor would help both its community and Solid users.
MEGA client-side encryption
While MEGA offers just read-only access to files, the technology behind it makes it not only the first option I would choose for storing files online securely, but also something to be learnt from and inspired by. The encryption of any file is completely client-side, which means the service not only cannot decrypt the files without the user’s permission, but also cannot be compromised to intercept the keys or fake the data. The decryption key is passed around in the URI fragment section, which is something RDF can work with well.
Unlike the case with Tor, taking advantage of this approach does need new standards and technologies that are not available yet. The MEGA API is proprietary, and I assume research and development is needed for transport methods with client-side encryption, for ways of providing data access to services so that even the Pod provider is not aware which portion of the data is accessed by which service, and of course for the encryption and partitioning of RDF graphs themselves. But the end result would be the ability to rely on Pod providers that they cannot, by design, access or differentiate any data stored there, and only you and the services you permit will be able to access it.
Complete and autonomous data decentralization by design is the last important principle that is on the horizon, and, hopefully, will prevail and succeed. There are many milestones yet to be reached, but I feel the principles of both the Solid and SafeNet groups align. The data model of SafeNet seems to support RDF well, but it also seems to be very isolated from the rest of the world. I am not sure what is the current level of cooperation here, but I would very much welcome bringing the communities closer. SafeNet seeks to replace the current web ecosystem, but all that would be needed (though I imagine hard to achieve) is to tap into it.