Bluesky calls its store a \"PDS\" too, here's how it differs from a Solid pod
Same three letters, different problem, and on the property this page is really about, theirs is the stronger design. They also won the consumer race by any public measure, and we are not competing to displace them.
The naming collision
Both stand for a store of personal data that you can host yourself. After that they diverge almost completely, because they were built for opposite kinds of data.
Theirs is built for data meant to be public, posts, follows, likes, at large scale, where the hard problem is proving who wrote what and keeping millions of copies consistent.
Solid is built for data meant to be private, where the hard problem is deciding who may read each thing.
What their store actually is
A signed repository, structured as a Merkle search tree, closer to a version-controlled repository than to a folder. Records live inside it, changes are signed, and the structure produces diffs other servers can consume.
Identity is a decentralised identifier that resolves to a document holding the keys, the handle, and the URL of the server currently hosting the account. Because the identity is not the server, an account can move servers and keep its followers: the identifier stays, the pointer changes.
The server holds the signing key and the identity-rotation key.
What a Solid pod is, by contrast
Independent HTTP resources, individually addressable, typed by their Link headers, with an
access-control document beside each one, verified this session against a locally-run
server.
No repository. No signing of the store. No history and no diffs.
What secures it is the server and TLS.
The difference that matters, and it favours them
Their repository is tamper-evident. A Solid pod is not.
Because their records are signed and the tree is hashed, a third party can verify that a record was authored by the account and has not been altered, without trusting the server that served it.
A Solid pod offers nothing equivalent. Fetch a resource and what you have is what the server chose to give you. If the server changes it, you cannot tell, and on our deployment the server is us.
That is a genuine architectural advantage on their side, it is not one we can talk our way out of, and it belongs above the section where we say what Solid does better.
What Solid does better, stated smaller
Access control. Four permission modes, per resource, per agent, enforced on every request.
Signing everything makes sense when everything is public. It is a poor fit for data you want read by three people and nobody else, and fine-grained authorisation is where Solid put its effort.
Our own interface exposes two of those four modes, so we do not get to claim the full version of this advantage either.
The symmetry we are not going to use as a jab
Their identity directory is operated today by one company, and they have publicly said they would like it to sit with an independent body instead.
That is the same criticism we make of ourselves, our chain is four validators, all ours.
We are pointing at it as evidence that the problem is hard, not that they are careless. They are carrying it at a scale we are nowhere near, and they have said so publicly.
Where each one is the right answer
- Public social data, at scale, with verifiable authorship → theirs. It is what the design is for and it is working.
- Private data with per-resource permissions → a Solid pod, which you can run yourself, two commands.
- Both → they are not exclusive; nothing stops a person having an account on one and a pod on the other, and neither of us requires the other's identifier.
What we are explicitly not claiming
Not that pods should replace their store. Not that we compete for consumer identity: that race is decided and we did not enter it. Not that our identifier is better for their use case; generic tooling cannot even resolve ours.