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

1

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 .

2

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
3

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.

4

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
5

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?

6

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
7

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.

3 Likes
8

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
9

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.

3 Likes
10

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.

6 Likes
11

The following is from Digita’s “Solid in Short” series.

Episode 2. Data You Own and Data About You.

"The proposition of the Own Your Data Movement is not that you should own all data that is stored about you.

Solid was originally conceived to replace social networks like Facebook and not so much to be used by companies or governments to give their customers or citizens control over their data and transparency about what their data was used for.

And the personal data which is stored on social networks like Facebook are of a completely different kind than the one that are stored by companies or governments. Indeed, while it is only natural that you yourself can update or delete your information at Facebook, it is of course unthinkable that you simply have write access to your data at your bank or your government.

According to personal information management theory, this is because social networks store data of you like your likes, your photos, your friends and your messages while companies or governments store data about you. The theory says that its only fair to have ownership over the first kind but not over the second.

Why is it important to distinguish between data you own versus data about you? Well, its about expectations. We’ve noticed that companies are often hesitant to participate in a Solid ecosystem or a personal data web because they think it will lead to a situation in which their customers have full data ownership and can thus do anything (what) they want with their data.

It is only when our expectations about data ownership are in line with this distinction that companies will participate in a personal data web and hence give Solid a proper chance to succeed."

^ Digita

===================================

There is a big question of who gets to decide what is data that we own and what is data about us, that we presumably don’t own.

This ground should not be given up to companies or governments because they are “hesitant”.

For every piece of data, it should be proven why individual persons should not be in control, before it is conceded that the data is not owned by the person. Otherwise control over everything in the gray area and even beyond will be given up.

In fact, a person should be able to claim anything… that they are 10 feet tall, have a trillion dollars, whatever. That is their data.

Whether it is verifiable is another story. Companies and governments should rely on verifiable data but that doesn’t mean that the verified data is theirs to keep, unless they are the verifier, which the person or customer has in some form to agree to. Your bank may be the verifier of your account balance, but they are not the verifier of your address.

The power that a company or a government has over your data should be as narrowly defined as possible, and even then should only be granted either by your written permission or required by laws subject to democratic controls.

2 Likes