The intention seems clear, but why decentralize data? Is it the only/best solution to data control?
What about simply creating a data coop (i.e. company) to own and control data, and sell memberships in it? i.e. solve data ownership with ownership rather than technology.
A central data coop would eliminate a lot of technical inter-linkage between different applications and repositories, and make everything much simpler. Would it not?
Such a data coop would be surrounded by a forest of application providers that have a single central data platform for sharing data among them.
It’s possible that there might be different competing data coops, if anyone is concerned about lock-in.
We pick the coop, the coop does not pick us. This is no different than leaving PODs where you want to in Solid, except that it eliminates the problem of applications interlinking so many data repositories and other apps, passwords and access layers all over the place, blockchains being immutable, etc.
Please tell me what is missing in this simpler solution. The TSIS Project (tsis.info) is based on it.
Why is decentralization central to solid? Because what needs to change is not just the location of the data but the role of data in society. We currently have a model where we all give our data to a few centralized providers who give us services and sell the data to others. In this model, the few who have the data (Facebook, Google, Amazon, etc.) completely dominate the marketplace. We want a software ecosystem in which there are many providers who can not profit from our data in the same way. That means changing not only where the data is located, but how it is accessed. By data we don’t just mean your files and photos, we also mean your tweets and comments and likes and clicks … these are what the companies make money off of. Having our files and photos in a private place is all well and good, but it does nothing to keep Facebook from amassing all the other bits. It’s this social data that we are most concerned about. (Solid = SOCIAL linked data). Instead of everyone puts their social data in one place and everyone has to go to that one place using that place’s software we want instead to be able to keep our own social data (doesn’t matter where) and anyone that wants that data has to come to us and there are multiple softwares to do that. Additionally, the semantic web means that meaning is supplied by us in the smart data rather than being applied by AI on smart servers. Simply having coop storage spaces would do nothing to reorient the flow of data or change the software ecosystem.
The idea is a data coop designed by us to do nothing but host data. Not sell it or farm it, simply act as a repository, separating data from application. This does everything that you suggest, it seems to me.
Centralizing data is not the problem, it’s how the data is used. Centralized data is easier and cleaner to use, easier to permission, and much less complicated to integrate. It’s how the data is then accessed and used that’s the problem. Is this not much easier to manage data access with a central coop that we design?
How would such coops have any impact on the flow of data or the application ecosystem? What part of them would make software work any differently than it does today? How would me storing my files in a coop in any way create multiple alternatives to Facebook?
The impact would be much smaller, and simpler, which is a good thing. The key point is that data would no longer belong to tech giants to do with as they like. Is this not the end goal? Future facebook apps would pull data from the coop, but would not own it. It’s simply drawing a line around data ownership and control.
Common to these objections seems to be the idea that apps like Facebook will ever switch to Solid. I think it is much more likely that they might switch to a data coop model, with one source for data.
Your last paragraph is a perfect example of why Solid is needed. In your model it would be possible for Facebook to simply switch to the coop and keep using the same data model and app structure. If Facebook were to switch to Solid (or more likely be replaced by many better alternatives), they could not keep the same data model or app structure.
I don’t see the existing Facebook ever switching to either Solid or a coop, to be honest. However a new Facebook would be almost infeasible if all the data is stored all over the place in Solid, with all sorts of structures and access controls. Second, the data coop would dictate data models and access, not the new Facebook.
Please compare trying to create Facebook on Solid versus a centralized data coop we design and control, with access controls of our creation.
If you want to believe that Solid versions of social media are infeasible, go ahead. I’m choosing to believe some of the greatest minds on the web who believe it is feasible. Your answer “the data coop would dictate the data models, not the new Facebook” is not an answer, it says nothing about what the data models would be or how they would be enforced. Solid has a very detailed game-plan of what the data models would be and how they would work.
Are you saying that the details are such that a new Facebook could be built on the current Solid design? If so, it’s far more advanced than I’m aware, or as suggested by the conversations I read.
I’m asking a foundational question about the direction of Solid, because my general sense is that feasibility is not yet assured, and the questions coming up in these forums and chats seem fundamental. As I said above, the TSIS Project is designed on a simpler data coop model, and I want to know what’s wrong with that.
Solid Pod Server works fine on my Raspberry Pi, with a growing number of working apps.
The whole idea of Solid is that information is decentralised in such a way that I have complete control of all my data, that no other company (nobody other than me) can view or access my information without my permission or sell that information to anyone else.
In your proposed coop all the information would presumably be on a single server but who would be hosting it and who would own the information?
The simple answer is that before too long it would be owned by a single Facebook like company that would have access to all my information and could sell it just as Facebook does now.
Also in your proposed coop you intend selling membership. There is nothing to stop you setting up such a coop, charging for membership, and seeing how many people trust you with their information and their money. If you can persuade the many millions of people who are currently using Facebook to change to your coop you will soon be a multi-millionaire. … Good luck with that! … And good luck managing those many millions of fully paid up coop members who would presumably have as much management authority in the coop as you would.
As for me. I think I would rather put my trust in Solid.
This is not what happens in coops, they can’t be bought out unless a majority of members approve. The coop owns the servers and data, the members own the coop, and the coop rules dictate who can be a member. Why would you even want to sell your membership to a private company? Why would you give permission for anybody to even access your data if you don’t want them too? I don’t follow these objections. It seems that the nature of a coop may not be clearly understood. They are easily made impervious to these shenanigans.
Disclaimer: I’ve only watched the two intro videos of TSIS and read a little bit and I’m not an expert on Solid either. This is just my perspective
As far as I’ve seen, Solid and TSIS have different goals. On the one hand, Solid tries to be a tool or “way of thinking” which gives the user control about his/her data. On the other hand, TSIS tries to create a platform for getting people together to solve real world problems.
I’ll try to summarize the key goals of both of them. Feel free to add missing points or mention it if I understood something the wrong way:
Solid goals
Give the user control about his/her data
Give the user the choice of choosing an application to handle the data
Give developers the ability to reuse data created by other apps
Which in turn should be achieved by:
Having pods with a defined API
Defining standards, so different apps can work with the same data (->interoperability; easy to switch between apps)
Store data in a way which is understandable by machines (-> interoperability)
Foster an ecosystem of apps which use these standards
TSIS goals
Solve real world problems
Encourage good behavior
Which in turn should be achieved by:
Providing a platform which makes collaboration easier and more effective
So solid is more like a library/standard which is used to build apps, while TSIS actually tries to build an app for solving some issues. Also from my point of view TSIS has several values baked into it (encouraing “good” behavior which indirectly punishes “bad” behavior), while solid is much more open to diversity. In fact, I am deeply concerned about points 1 and 2 (Identity and Reputation) of the TSIS agenda which in that way aren’t part of Solid as far as I’ve seen. But that’s just my opinion, we can discuss about it here if it is related to Solid or in a private chat if you want.
A very good summary, but allow me to clarify the relationship:
TSIS is an infrastructure of 7 overlapping layers/systems, plus some application components, but most of it is an open library/infrastructure. Like Solid, TSIS has a view on the ownership and control of data, underneath the 7 layers. Solid goes for decentralization whereas TSIS uses a data coop to centrally control shared data. Solid stops there, and TSIS continues.
Does that make sense? Not all of this is on tsis.info, owing to the amount of detail involved, but you get the picture. For comparison to Solid, the key thing is the approach to shared data hosting and ownership.
Further layers address specific problem areas that relate to social computing, such as user identity validation, optimal information sharing, delegation and activism. These are ultimately democratizing priorities.
The question is, if you were to design a large application requiring a lot of data for a lot of screens, like a new Facebook, would it be much easier to build it on a data coop or on Solid? And if the coop were legally structured and organized appropriately, would it not be much simpler and more reliable?
I am pretty confident, that Facebook features like joining groups, subscribing to channels, liking and commenting things, and chatting in private are feasible in Solid. Something which seems a bit more tricky is the discovery of new relevant content, but I guess that’s also doable with Solid (e.g. subscribing to a broader topic or maybe an app analyzing your usage and suggesting you to subscribe to XYZ based on that).
I think projects like mastodon and peertube show that social platforms like Twitter and Youtube don’t need one central server, but could be federated across multiple servers. I think the question if completely decentralized systems are also capable of this still remains to be answered, but Solid also doesn’t prevent combining federated systems with solid pods. For instance, the discovery tool could be implemented by utilizing a more or less centralized topic database which maps “user shows interest into heavy metal, this and that” to “user may be interested into: feedXYZ, feedABC, …”. The rest (subscribed feeds, chats, …) could be handled within decentralized solid pods.
My question is not about doability, because anything is doable with enough resources, but about what’s easier, probably much easier. Personally, I see using one organized database to be much easier than figuring out how to use an unlimited number of separate databases and/or Pods together. Don’t you agree? I’ll be surprised if not. If you don’t share this expectation, we must be looking at different technologies.
@tjhorton coop v pod-servers aside, do you see the benefit of separating application from data? And the ability of different apps to read, write and mashup each other’s data?
I think those are very important benefits of Solid and why I I’m such an enthusiastic supporter of the protocol.
I am though unhappy with the pod server / service model for many reasons, and some of this would also apply to a coop model. Although I think the problem with a coop model is how to get people to create such coops and use use them in ways that can scale. We see this kind of problem with federated systems which tend to gain an enthusiastic early user base, but then stall.
Adoption is going to be an issue with every new system, but I’m curious how you could get coops set up, and get people to join them.
But my main issue is with using servers at all though, for reasons of security and the risk of them becoming centralised by business. Servers are the core of the problem IMO.
Decentralization is an option rather than a discipline.
If there is only one good POD provider, it comes to be the “data coop” as you described.
But one day your mind is changed and alter to another POD provider, you have the freedom to do so with a low cost since the protocol is standardized. That’s it.
So at the end of the day, there can be many data coops. People just pick their own preference. That’s “Decentralization”. Again, it’s an option rather than discipline.
If it is doable there will likely emerge libraries which will abstract the hard parts away, so it becomes easy to use (despite maybe having a more complex system). And I think what we are looking for is an alternative which (1) enhances several things (e.g. data ownership), (2) can be implemented on a broad scale and (3) doesn’t lead to bad side effects. So easiness is part of the decision, but not the only question we have to ask.
The problem I have with comparing is, that I don’t really have a view of how the data centers you speak of would work. Two guesses from me how they could look like:
If they only provide an API endpoint for storing and getting data, it would be pretty much the same as Google Drive or Dropbox but with the expectation that it doesn’t sell the data. I think in this case it would require the same effort.
If they process some data, e.g. making a profile of a person with several interests, it becomes more specialized and similar to Facebook, Twitter and co. In this case, apps which fit this specialization would be easier to make, apps who don’t would be harder (or at least the same as with Solid).
If the first is the case, I would prefer Solid as it doesn’t depend on trusting a centralized service. Depending on it means, that we have to trust the server maintainers that they don’t misuse their power and keep the service available.
If the second is the case, I think Solid and TSIS coops have a different aim. Solid tries to be open for many different use cases, whereas TSIS coops in this scenario would be rather limited in terms of usage. Furthermore I’d prefer federated systems (Matrix, Mastodon, …) which are also specialized, but are based on open standards and give the chance to choose the storage.