Why a user should choose Solid pod and not a classic server?

Hello! I am interested in Solid technology and I would like to clarify something in my mind.
So why a user should choose to store his data in a pod and not in a classic server that he administers?
Suppose facebook won’t store data in his servers, as solid suggests. Instead of asking the users WebID it would ask the url of the central database that the user uses. What’s the difference of using solid pod?

One of the pros I can think is that data are organised in Linked Data form, so it would be easier to find them and retrieve them because of the URI.

Also in Solid if the user changes his provider his WebID would change right? So we can not claim that a pros of Solid is that a user can move his data without notifying for example Facebook.

What am I missing? Thank you in advance for your answers :slightly_smiling_face:

Hello! The problem is when you want to give your friends access to some resources. In Solid, people access the data (through their browser), servers do not.

You could consider that http://facebook.com is a webid, and so give access to that webid, but it would somehow defeat the purpose, because you could directly give your friends access to your resources instead. Adding facebook.com as a friend is similar to the concept of aggregators presented in this use case: https://www.youtube.com/watch?v=oT8sft3YM54

If the user changes his provider, he just needs to inform his friends (just like email for that matter).

From my understanding, an essential part of Solid are the specifications and standards it proposes. I think of Solid pods as a standardized Dropbox. So without knowing the specific implementation of the pod, developers still have a common interface to work and store data on the pod.

The advantage over a “classic” server, is this common interface: You could use any app with your pod, which makes use of these specifications. This should make it easier to select from a multitude of apps and switch them if necessary. If it would be a normal server, the app would have to be customized to the behaviour of it.

Linked Data will be useful to make the apps interoperable and to reuse data which other apps generated (but I’m no expert in this…)

Yes, there’s been a discussion about this already in the forum somewhere…¹ I think one idea to solve this was a decentralized webId, but I’m not sure how this would work.

I also want to note, that Solid also enables several applications which don’t require a backend. The user loads the application, points it the webId, and then the app uses the preferred pod of the user as a data storage. For example, the ToDo app itself won’t need a backend. It would only send requests to the users pod.

So in the Facebook example, it possibly wouldn’t have any servers itself. And when changing the webId one wouldn’t need to notify “Facebook”, but rather tell the friends that the webId changed so they still know where to find me. And then use a different webId in the app. I personally have some doubt that it will be possible to create a Solid-Facebook with the same functionally without a backend, but I’m looking forward to the different social apps which will emerge. Also questionable if one even would like to copy FBs functionality… :))

  1. Found it: Any plans to make WebIDs independent of service providers / prevent vendor domain lockin?

@A_A Thank you for your answer.
Regarding the part you refer to specification, yes I agree that’s a strong advantage. But also we could say that there might be proposoded a standardize way to organize and administer a centralized server. But solid is the one who already done it and proposed a standardized way. So yes I agree that’s a pros.

Regarding the part of a front-end only app, we could say that the same applies for centralized servers. The app would ask the user to provide the url, that the app could address to retrieve the data.

Thank you for your answer.
In the same way, friends could exchange the url of their servers…

There are a couple of answers to your questions I think, one of which has been mentioned already, namely the standardized API that Solid sets. This allows apps (and bots, and other agents that use the Solid API) to work with all servers that support the Solid API.

Another answer is that if you want to set up your own server and have your Solid Pod on it, you’re more than welcome to do that. But most users probably aren’t tech savvy enough to set up and maintain a server of their own, so they would probably use a service provider that does it for them. Either way you choose, as long as the server conforms to the Solid API, it you can use any apps that uses it.

The point is really the API that allows clients and servers to exchange data in a standardized manner - and that you as the controller of a Pod can control who should have access to the data of that Pod. (These access controls are also standardized btw, so you can use any app/service that allows manipulating access based on this standard to manage access control on your Pod.)