What data is the data that users of Solid own and control?

Given the focus of Solid on user ownership and control of “their” data, what is this data and where is it, considering:

many implementations I’ve seen discussed include mixing and matching resources, resource descriptions, resource representations, abstraction, proxy, caching, etc …

if the user provides a solid server, for their pod, either directly or through a third party app, which might locally or remotely have its own such things, Turtle, and then the server then recreates and maps that provided data to a backend implementation of a graph database where it’s then broken up and replicated and distributed in clouds etc … obviously the users have no idea about any of this .

is it, or will it be, good practice for any and all of this to be disclosed to users and granularity bought into, rather than just merely having a user think they just own and control their data in abstract (the virtualized illusion of), rather than actually owning and controlling the literal and concrete data which may be more evident by other some other decentralization projects .

To what extent does / should the POD provider be an APP that also requires access to your files and folders in order transform the data you provide (which you own and control) into a data that the POD can best manage and make efficient.

1 Like

what is the specifications expectations for a user around the idea that the user is logging into a POD (at a specific “location”, not merely content addressed or virtualized however the POD provider may see fit without making explicit to the user prior) and WITHIN that location which the user believes they own and control the INSIDE of …

The user uploads one Turtle TTL file, only for the POD provider to then parse it and recreate inside the POD providers triplestore / graph database in a location and system separate from the users POD and then present it back to the user as a virtualized view making it still look like it’s a file within a folder at a specific location.

So in this example, what is the data that is the data that the user actually owns and controls?

Do the users of POD providers automatically give POD providers access to the data they are uploading in process? Or are they / should they be authorized by the user for such purposes beforehand?

The reason this is interesting can be illustrated by the user uploading to private folder client side encrypted and content hashed file which may actually be a Turtle file with RDF triples in it, but then the POD provider for instance would then not be to mess with it like it does when the user uploads Turtle TTL files. In this instance the POD provider would need to be authorized and given access control (in SOLID) and keys (outside SOLID) to decrypt that file in order to then run its process of making that RDF efficient for its proprietary system which may include replicating and recreating it “elsewhere” than where the user actually first uploaded it.

BUT the user should be authorizing any and all of this with the POD provider as a trusted app.

I think some say that solid is Not an app, even though I disagree with this concept, you still present a reasonable argument. A pod provider may very well be deemed an application, depending upon the legal argument you present. It’s almost as though you can look at solid as Facebook, or a sort of Facebook. Facebook is an Application, Facebook maintains its own servers similar to a pod provider maintaining their server for the pods they serve. They are providing a very similar thing to Facebook. They are providing an account, with a username and password, access to other applications, And the ability to store data on the server. I don’t see how pod providers would not be looked at iany different than Facebook in that regard; just a different type of dashboard, with very similar features. So if a pod provider Is providing very similar things as Facebook, and if Facebook is considered an application, then it could be argued that pod providers are a application as well.

1 Like

Definitely, and another way I’m thinking through it is asking why wouldn’t a killer app just also be a Pod Provider that has extra built-in features utilizing its proprietary implementation instead of needing to deal with the complexity of decentralization when having an app needing to deal with any random minimally spec compliant implementation?

I think Solid, being built on http, will be only client side when autonomous serverless networks come into their own, which looks to be soon. There will be a layer in the client that translates the http to other transport protocols. So your pod would be just a centralized http interface within your client, and from there it would keep track of encrypted and replicated and content addressable data in networks with other transport protocols. If you want to go to another pod or some other kind of server, another interface for that one would be downloaded from the network to your client and used similarly. All the centralized http servers would just be on your client. So there would be no pod providers.

I’m no expert though, and there may be reasons why this is impractical. But I’ve just been watching this unfold for a while, and that’s the way it looks to me.

2 Likes

This is a step towards what I call Solid on Safe.

When you get to that point, it then becomes unnecessary to use http in many use cases because if your data is on decentralised storage your apps can be too - with the limitation that they are client-side only.

There will still be use cases which prefer server-side code, but many would do better as decentralised client-side apps because of the advantages this can bring in security, availability, anonymity, censorship resistance and so on.

2 Likes

I do think though that the separation of data and applications is important and data interoperability and other things in the ecosystem will make Solid a very useful interface for applications once it gains a wider following even if the http part itself is abandoned.

2 Likes

I think putting it this way regarding the separation of data and application is a good description, because one thing I am afraid of seeing based upon some descriptions of Pod Provider Services is there seems to be an implied tighter coupling (decreased separation) between data and application when a Pod Provider has a Killer App that utilizes proprietary implementations of Pods which affords some sort of side-loaded features without the Pod Provider needing to be authorized in the same manner as a Application would need to be.

2 Likes

I think with the current model the incentive on pod providers to “differentiate”, make sticky, and centralise, and then stray into dark patterns will be strong and I can see this undermining Solid or holding it back because separation and openness is crucial.

This seems inevitable with a service based model.

5 Likes