Proprietary Solid Pods


#1

Is there a general consensus around the idea of Solid Pods that afford proprietary layers of features ?

Such as, XYZ is an awesome Solid App, but it only works on certain pods (maybe subscription based, etc)) because it requires extra features that aren’t a part of Solid itself .

What would then be the expectation of using that proprietary pod and app for a year and then thinking you can just switch pods and keep using the app, or you no longer need to use the app, and you want to move to a non-proprietary pod ?


#2

Have you already taken a look at this discussion about switching pods?

I think the main problem they discussed was, how links to your pod get update when you move the data and how the webId could be switched. But you can read it up there.


#3

Some might argue this is a feature, but to me it is a big hole in the ‘pods as a service’ model.

I think this because it is an easy way to create lock in: entice users with attractive extras that are not easily available elsewhere. This would undermine one of the key goals of Solid - ability to transfer your data with minimal cost and no loss of service - in which case we will have recreated the conditions for those with deep pockets to centralise, capture and exploit.

Business will inevitably do this so long as it is a way to increase profits, and I am not sure that there’s a way to change that while retaining pods as a service at the core of Solid. It certainly doesn’t get much discussion, which is baffling, because to me it seems an obvious problem with the economic model of Solid that breaks the essence of the project.

It isn’t that it can’t be solved at all, but I don’t see how it can be solved while using pods as a service.

I think the main solution is seen as making it easy for individuals to run their own pod, and to get user owned pods into homes by various means, but a credible route to this is not being elaborated. To work it would need to be easier and cheaper, and obviously so, to a degree that marketing by corporations would not be able to capture the bulk of consumers. Meanwhile we see corporations push TVs, digital assistants and ever more abusive devices into people’s homes with ease, and all we can do is shake our heads and hope for regulation.

IMO we need a technical solution that can’t be captured and centralised, but as I say, I’m open to hearing why I’m wrong.


#4

Pods as a service could happen first as a non profit service where the need is greatest. Teachers, of which there are millions, many of whom are tech savvy and sick of their unions. Yellow vests. Environmental groups. Or just plain communities and towns who see the value.


#5

One thing I want to add here is, that several features which seem to require additional server capabilities (e.g. cron jobs, backups, etc) could possibly be separated from the pod itself. The pod would store data and settings, and a different server provides the additional features. For instance automatic backups could be done by a different company than the host of the pod server. I think such a solution is possible for multiple use cases, but definitely not for all. And it doesn’t solve the issue with the url lock-in, so it is no solution for centralization in general.


#6

I would agree, essentially those features can be distributed to an decentralized app that manages specific normal RDF on normal Pods .

The application logic of specific apps should not be baked into pods “out of band” of normal Solid per se .

This is why I’m also surprised to see the sentiment behind the idea of a address book in the other post being thought of as a pod, rather than a normal decentralized app architecture … in that said example, a particular pod (not pod service) should not be proprietary either regarding app features … because the entire point of decentralization and privacy sentiments of Solid and similar is that the data is local to you, not the app … the app shouldn’t need its own local metadata about you in order to provide you value .