Hello, I’m looking for decentralised storage for my photos and videos…perhaps later more data?
I understand these ‘Pod’s are decentralised, however I notice the Pod providers’ servers are with Centralised companies like Amazon etc.
This seems to bring in the larger question, unless I’m missing something, of the utility of decentralised services? I guess it spreads the wealth a little right to smaller businesses?
I am interested in blockchain too, however some critics have suggested blockchain is just another form of ancap (anarchy capitalism)? Spain has this CoOp business model called MonDragon if you’ve heard of it, do you think MonDragon could be applied with this decentralised and blockchain ideology?
I’m looking at Odysee or DTube for videos, as it’s nice to earn some rewards, rather than a centralised Alphabet like company.
Anyone can start a Solid server, so the point of decentralised services is that you don’t have to rely on big players, but you can if you like what those give you. Similar to how you don’t need to have a Gmail or Outlook account to be able to use email.
Blockchains don’t allow you to remove or update data, which may or may not fit your use case.
I’m not familiar with MonDragon.
(I will also say that the Solid ecosystem is still very immature, so unless you are fully bought in to the idea of Solid, you probably won’t find the user-friendly and accessible tool you might be looking for.)
Thank you 
In addition to Vincent’s points, I’d like to say some technical aspects.
In general, there are two ways in which decentralized services are implemented: distributed and federated.
Tox, Blockchain, etc, are distributed, where each user is a node, which holds its own data (for blockchain it’s the whole blockchain, not just the node’ own), and performs its own tasks (computation, messaging, consensus, etc).
(Email,) Mastodon, Matrix, etc, are federated, where there are multiple servers that can talk to each other; users register accounts on these servers, or their own servers. Usually the servers also provides APIs for clients to use.
The two models each have their own strengths and drawbacks, and their respected challenges. Each of course has some variants.
Solid can be considered federated (although not entirely), so you see the potential issue of being hosted on Amazon cloud or some other cloud servers. But bear in mind that this is the issue for all federated services, not just Solid.
The key point is, as Vincent said, that you can freely use a different server (or set up your own) and that does not give you any disadvantages. This any is serious: you will not be cut off from interacting with others on existing servers, and you will not lose any functionalities (as long as it’s in the protocol). The design of Solid also provides more flexibilities such as the potential to use multiple servers simultaneously, or migrating to a new server while marking that on the old server.
Of course, there is still the server hardware limitation, which no technology can circumvent.
I’m not familiar with MonDragon as well. But I’d encourage you to also think from the technical perspective rather than ideological perspective – what does the interaction model look like, and how is (or is not) it different from other technologies?
Economics and control: Because Solid splits the apps from the data using a standard universal API, it makes a new market for pods and pod-like things, so some people run their own servers, some use services based eventually on AWS, you can form coops or clubs to manage pods, etc. You have a huge choice of the social and economic structures you can use around storing that data. (unlike blockchain where when you have picked your chain you have picked your commune).
I have all my Photos and videos and music on my pod, on my own domain name, a Mac Mini running CSS and SolidOS. I sync it using Mercurial with my laptop which also runs CSS.
Music: SolidOS does very simple things with audio files - but you can listen to music. Improvements welcome!
How does Solid work with apps that store shared data between users? Such as chat, social feed, collaborative docs, etc. What if users disagree on where to store their data, eg. one user’s Pod stores data on Amazon, but the other user does NOT want their chat data to be stored on Amazon? Is there a way that agreeing on a storage option can be done in the protocol-level?
Eg. user A initiates a shared-data app (eg. chat) with user B and provides a list of storage options it finds acceptable (eg. Amazon, GCP). User B accepts/deny based on its set of acceptable storage options. If no agreement can be found programmatically, then the apps prompt the users to find a solution.
Solid has ways to block users and apps. It would be fairly simple to block all apps originating from a given origin or users from a given Identity provider. But, to block a specific storage option is not part of the current access control. It would need to be done at the client level. Since users can have multiple storages, it might not be possible to even know where a user stores a given piece of data.
A general design of social apps that relates to this issue is to store my chat messages in my pod and your messages in your pod.
The storage issue takes on a legal dimension when we get into questions of the GDPR which is why we list the physical location of various storage providers on solidproject.org.