When we open an address on the Web, a familiar sequence begins. A name is queried. The query leads to an IP address. Packets travel to a machine capable of responding. A protected connection authenticates the server and carries the data.
In the end, we receive bytes from a place we were able to reach.
This architecture answers one question very well: where should I look? By itself, it does not answer another: what exactly did I receive?
TLS authenticates a relationship with an identity recognized for a given name. Signatures can authenticate publications. Applications can check hashes and formats. Today's Internet is not incapable of verifying data. The point is more precise: the identity of the object is usually not part of the reference used to locate it.
This is why address and object change together in our everyday experience. If the server moves, the path must be updated. If the domain disappears, the reference stops working. If two machines offer the same file, the user relies on mechanisms outside the address to trust that both deliver the same thing.
The address leads us to the provider. It does not necessarily identify what the provider supplies.
The address accumulates too many roles
A URL can indicate a scheme, authority, path, and parameters. It is an expressive tool, but its interpretation depends on infrastructure and state that can change.
The domain depends on resolution. The IP address represents a logical location for forwarding. The path is interpreted by the server. Today's content can be replaced tomorrow without changing the URL. The same representation can appear at another address under a different URL.
None of this is an accidental flaw. Mutable references are useful. We want a newspaper's address to show the current edition and an organization's profile to follow its latest publications. The problem appears when a mutable reference must also serve as permanent proof of the object it refers to.
An address can remain the same while its content changes. Content can remain the same while every address changes.
They are different identities.
When the bytes take part in the name
An alternative is to derive the reference from the content itself. In its simplest form, a cryptographic function takes the bytes and produces a digest. Any relevant change produces a different result. Anyone who already knows the reference can repeat the calculation and compare it.
The idea predates PRP. RFC 6920 standardized hash-based names to identify resources independently of a server and verify the binding between a requested name and the data received. Systems such as IPFS use content identifiers to reference data without incorporating its storage location into the identifier.
This change may seem small, but it alters the trust relationship.
If three providers present bytes for the same content identity, the requester does not need to take each provider's word for the object. It verifies the match. A cache does not need to be the origin. A replica does not need to retain the address of the first copy. The channel must still resist interference and unavailability, but it ceases to be the sole guarantee of the object's integrity.
The location requires less trust because the object participates in its own verification.
A copy does not become another object
In a location-oriented model, moving data requires updating references or maintaining a chain of redirects. In a content-oriented model, identical copies preserve the same content identity.
This allows three functions to be separated:
- identify: determine the exact sequence of bytes being sought;
- discover: find candidates that claim to be able to provide it;
- transport: obtain the data through an available path.
The provider can change without changing the object. The transport can change without changing the object. Multiple providers can coexist without gaining the power to redefine the object.
This separation also exposes an important difference from the previous article. Blocking a location can make one copy inaccessible through that path. It does not cryptographically revoke the identity of the content or invalidate copies obtained from other providers.
Persistence, however, does not emerge from an identifier. If no one retains the bytes or agrees to provide them, the object remains identifiable and unavailable. Knowing exactly what is missing does not make the data reappear.
Verifiable does not mean true
A content identity answers a narrow question: do the bytes received match the bytes committed to by this reference?
It does not prove who created the object. It does not demonstrate that a news report is true, that a program is safe, that an image has a particular license, or that its circulation is legitimate. Nor does it explain, by itself, why someone should trust the initial reference.
Those questions belong to other relationships:
- a signature can bind a statement to an agent;
- a policy can authorize access or publication;
- metadata can declare type, title, authorship, and license;
- a controlled reference can indicate which version is considered current;
- discovery mechanisms can locate providers;
- local decisions can accept, hide, or reject objects.
Separating these functions does not make them less important. It makes each decision visible and verifiable through the appropriate evidence, without asking the incidental location of the bytes to represent all of them at once.
A hash alone is still not enough
Saying “the hash of this file” omits necessary decisions. Which algorithm was used? How long is the digest? Does the calculation include only the bytes, or a descriptor as well? How are large files divided? How do we distinguish profiles that interpret the same sequence differently? How can one part be verified without receiving the entire object?
An interoperable identifier must incorporate these choices or refer to them unambiguously. Otherwise, two programs can display the same text and calculate incompatible commitments—or accept interpretations that should fail.
There is also an unavoidable consequence: immutable content cannot be “edited in place.” Changing one byte creates another content identity. This property preserves the past, but requires a separate mechanism when people want stable names for successive versions.
Immutability and updates are not opposites. They occupy different layers.
Content as an ALIAS use case
In PRP, ALIAS is a shared reference with which multiple independent participants can associate. Its text can represent an interest, a service category, or specific content. The protocol defines how that text is canonicalized and turned into an ALIAS-class SCIR.
To find a file, an application can include a content identity in that text using a shared convention. The convention determines how to represent the object's hash algorithm and digest. Applications using the same canonical text and reference suite form the same ALIAS, even on different machines or networks.
Imagine three participants keeping copies of the same document. They can associate with the corresponding ALIAS. Someone seeking the document queries that reference and may find multiple candidates. The application selects a provider, retrieves the bytes, and checks them against the expected content identity. If one provider becomes unavailable, another can offer the same copy under the same reference.
The responsibilities are straightforward: PRP discovers participants associated with the ALIAS; the application defines and verifies the requested content. The suite used to form the ALIAS and the algorithm used to verify the file are separate choices. For partial transfers or simultaneous retrieval from multiple providers, applications must also share rules for splitting, reassembling, and verifying blocks. Merkle trees are one option for that verification.
A participant can associate with an ALIAS without possessing the expected bytes. The application therefore verifies what it receives from each provider. This verification allows replicas and caches to be used without giving them authority to redefine the object.
The name that follows the versions
People rarely want to memorize cryptographic identifiers. They also want to ask for the current document, the latest version of a program, or someone's most recent publication.
An application can maintain a stable ALIAS to find participants distributing updates to a publication. These participants might provide a statement signed by the publisher identifying the content of the current edition. The application checks the signature and version rules before accepting that statement. Authority comes from the publisher's signature; association with the ALIAS remains open to multiple participants.
The ALIAS text can remain unchanged as new editions are announced. Each edition retains its own content identity, allowing copies of earlier versions to be verified as well.
Thus, “what is the current version?” and “are these the bytes of that version?” cease to be the same question. The first depends on an updated statement. The second can be answered locally through content identity.
From the location to the object
The previous article showed how addresses become imperfect substitutes for content, services, and conduct. Content identity corrects part of this confusion: it allows an object to be named and verified without making it the property of a location.
It does not eliminate the underlying network, guarantee availability, or decide policy. We still need to find agents, choose paths, establish relationships, and evaluate statements. But these functions no longer need to pretend that yesterday's address is the permanent identity of everything that passed through it.
When we know what we seek, we can change the where without changing the object.
The next article applies the same separation to people and services. If a publication does not need to belong to the server that hosts it, why should an agent's identity belong to the platform that maintains its account?