Pod Provider Listing Site

Feel free to add to the list of POD providers:

1 Like

Added the providers listed at https://github.com/solid/solid-idp-list/blob/gh-pages/services.json :slight_smile:

1 Like

I have registered a pod on this site https://solid.authing.cn/ did not get an email conformation of my registration however, the pod was created.The password I used to set it up does not work, and Is there a reason there is no email conformation for this site when a pod is registered?

how do i reset the password?

is there a “charter”, a “code of conduit” for a “Good Provider” like :

  • I promise to never commercialize the use of the POD,
  • I promise to never block a user that want to keep away for my service…
    … and other basic garanties ???
1 Like

Do you think this can be effective? How can you hold a company to account? And when another company acquires it, what then?

I’d be concerned that, just as Google had don’t be evil, and all those big surveillance companies (Facebook, Google, Microsoft etc) have signed the Internet pledge, it is potentially counter productive - giving people a false sense of security. Facebook is constantly apologising for ‘mistakes’ but when we see their private emails, we find that - surprise surprise - their primary concern is growth and profit.

That is the law, the primary prose of a public company is to maximise shareholder value. So they will only sign up to things which will not constrain that - which means non-binding pledges and assurances. Essentially PR, or in other words misleading people.

Can anyone show how it can be made effective?


@happybeing there is no unilateral right of any company or person that is beyond the reach of the courts jurisdiction. Technically, these pods are considered digital assets which consist of electronic records that are owned by the person or entitiy that created the account. Just about any online account consisting of digital files that a person has authority, access and control over such as email, online bank accounts, social media accounts, blogs, cloud storage and almost anything that you do online that requires a party to log in is a digital asset and falls under the jurisdiction of the Courts in the event of some foul play.

The company must give Notice of any changes to there policy, and just because Notice is given does not grant the right of a company to breach the covenant of good faith and fair dealing. If a pod provider did anything to destroy the right of the other party or parties to receive the benefits of the thing, then that would be actionable in the Courts of proper jurisdiction. There is also the unclean hands doctrine, breach of promissory estoppel and many other ways one can protect themselves from a pod provider. The law of contracts is a powerful tool. There need not be a terms of use or privacy policy agreed to with regards to pod registration in order for a contract to be inferred or entered into. A simple offer to signup with a user name and password acts as an accord.

a public company does not have to maximise shareholder value, and non-binding pledges and assurances will not save a party were a contract is inferred, a breach of the same is a matter for a Court of equity. Besides the law of contracts, there is also Tort law.

Thanks for clarifying the legal aspect of this, but I don’t see that as answering the points. All of this applies already, yet it’s not effective, and has allowed a multitude of companies and large corporations to create a hell hole, mass abuse of privacy, that threatens the Web as all those who support the goals of Solid would like it to be.

So I don’t feel this is an answer to the challenge we face, nor the questions I posed. The law has not been effective so far, and even with the large improvements we’ve seen such as GDPR I am skeptical that it will be in future.

I had thought what you were referring to was what Smag0 stated, essentially, I believe he was asking, how do we know that pod providers will act in good faith and not do the things he was referencing; My apologies if I got your point of contention wrong. Do think that maybe pod providers should have an office of the consumer ombudsman?

@adventure no need to apologise. We’re all commenting in good faith and I think share the same aims.

I’m not sure what the confusion is from what you’ve said there, so I’ll say that my point is that I don’t see a way to hold any pod service business to account if their business interest leads them away from the things we want and originally sign up for. Whether under the laws you helpfully elaborated, a set of standards which providers sign up to, and so on.

Yes, we can move our data, but people don’t even switch services when it is easy. At the same time, businesses are already expert in capturing lots of users and then hanging onto them, because if they don’t they won’t have a business. We might choose to believe that the threat of losing users will keep them honest, but I think firstly we can’t be sure of that, so we should not bet the Web on it. And secondly, I trust the ingenuity and power of big business more that I trust their values, so I am pretty sure that if they find ways to make more money they will find ways to persue them at the same time as holding onto users even as they abuse our data, our privacy and our trust.

I may come across as paranoid or cynical in taking this view, but really I’m neither - in the past I was optimistic and trusted business as I do people, but have sadly had to change my position on the basis of what has happened, which I’ve observed closely with ever increasing dismay. I think we can only trust business to do what makes money, and for small local businesses that works because they have a stake in their communities. So they have to care about the impact they have on them. That does not work with big global businesses.

Many of us are supporters of Solid because we’ve witnessed those kinds effect with dismay and want a better system, where users control their data and their privacy. I think aspects of Solid are spot on (separating apps from data ownership, and enabling apps to understand and work with each others’ data), but there seems no way to keep pod providers honest once they get big. So that is my area of concern, and why I comment on ideas that clearly have that aim, in order to establish if they are likely to be effective or not.

Unfortunately I don’t yet see a way of fixing the pod as a service model and I’ve not yet seen anyone else with a solution. Which in turn is why I suggest we look at other storage options, which don’t involve pods as a service, such as ‘Solid on SAFE’ or another system that remove business from this critical aspect of the design.

Hope that clarifies!


I understand that is your position, we must all have faith in free market society, without being disillusioned that, all things tend to disorder and chaos.

Maybe in the future, big business will decentralize with Solid and create sister companies for the solid communities they serve.

During the interim, I believe that big business is essential to the success of Solid on a global scale. Solid is an ecosystem, and during Inrupts’ presentation, John, among other things, stated that, neither he, nor Inrupt had a full business plan or model, and that it was Inrupts’ position that everything would evolve over time. I believe that was an extremely honest, all be it, vulnerable position he put himself in but, he appeared to be honest, and threw himself on the community sword, my fear would have been, if he claimed to have had it all figured out, before it got off the ground, Solid would not be a real ecosystem.

An ecosystem needs time to evolve; over time, we will all have to adapt in order to overcome the challenges that lay ahead. I think that pod as a service is absolutely necessary so that some of these big businesses like can begin the path of decentralizing user data.

There is no code of conduit for being a good provider, and I think it would be difficult to have one in the sense of following it up.

That being said, we (as in the Solid community) might want to require some more fields, such as which support channels exist for a given provider, when adding providers to https://github.com/solid/solid-idp-list.

Any thoughts on which fields should be required? Should we require support channels? Some sort of public profile, that can be tied to the service?