A CID and a URL are not the same promise

A content identifier is a hash of the bytes. Ask for it, and you can check that what came back is what you asked for, without trusting whoever handed it to you. A URL is a place. It tells you where to knock, and nothing at all about what will answer.

What each one actually promises

A content identifier promises integrity. The name is derived from the content, so a wrong or altered byte produces a different name, and the check is arithmetic anyone can run.

A URL promises reachability. Somebody controls that address and will serve something from it. The web has run on that promise for thirty years and it works.

Neither promise implies the other. A content identifier says nothing about where to find the bytes, which is why content-addressed systems need a separate discovery layer. A URL says nothing about what the bytes are, which is why the web needs TLS to tell you who you are talking to and still cannot tell you the document was not edited.

What a Solid pod chose

A pod resource is location-addressed. It is an LDP URL, it is fetched with an HTTP GET, and its identity is its address.

That buys the things addresses buy. Any client can read it, including clients written before Solid existed. It can be updated in place and everyone who has the address sees the new version. Access control attaches to it, per resource and per agent, which is the layer a pod actually competes on.

And it costs the integrity property. Fetch a resource twice and you have no way, from the address alone, to know whether the second answer is the same document.

The cost, not softened

HTTP does have partial answers here. A pod response carries an ETag and a Last-Modified, so a client can detect that something changed since it last looked.

Compare what that gives you against a hash:

	content identifier	pod resource
Detects a changed document	yes, by arithmetic	only if you kept the previous `ETag`
Detects a server that lied to you	yes	no
Works if the server is hostile	yes	no
Reaches the bytes without a directory	no	yes
Updates in place	no, a new version is a new name	yes

The third row is the one that matters and it goes against us. A pod has no tamper evidence, and on our deployment the server is us.

Two words spelled the same

Worth naming because it wastes people's time. One content-addressed storage vendor documents an "Identity" feature. It is a naming scheme that gives a bucket a stable, updatable pointer, so a mutable name can front an immutable hash.

That is a useful thing and it is not a decentralised identifier in the sense this estate uses the word. It names storage, not a subject, and nothing about it resolves to keys or verification methods. Same spelling, different problem, and reading one for the other will send you down a long wrong path.

When each is the right answer

Publishing something that must be provably unaltered, to readers who should not have to trust the host: content addressing. Archives, datasets, software releases, anything where a wrong byte is a real failure.

Storing mutable personal data with per-agent permissions and in-place edits: an addressed resource. That is what a pod is for, and the immutability of a hash actively fights it, because erasure and correction have to remain possible.