ProtoSpeech Foundation · April 2026

Deixis

Identity Through Content.
Location as Incidental.

Content-Addressed Resolution Protocol

Resolution cascade

REQUEST AFC2D81
01 · Local Cache
device/AFC2D81
MISS
02 · Local Network
homelan/AFC2D81
MISS
03 · Known Node
mirror.blog/AFC2D81
✓ HIT
04 · Origin Fallback
author.blog/AFC2D81

On the Name

Words that point.

Deixis is the linguistic term for expressions whose meaning is determined entirely by context rather than fixed reference. Here, this, now, I — these words do not have absolute meanings. They point. Their referent is wherever the speaker stands when they utter them.

"Give me AFC2D81" does not mean "go to this server." It means find this, wherever it currently exists, from where you are.

The meaning resolves outward from the requester — the same way deictic expressions resolve outward from the speaker. Local cache first, then nearby nodes, then the broader network, then origin. Identity is the hash. Location is incidental.

The Core Principle

Content identity is its hash.

In conventional networked systems, content identity is its location. A file lives at a URL. If the server at that address goes offline, the content ceases to be accessible — regardless of how many copies exist elsewhere. The address is the single point of truth.

Deixis separates these concerns entirely. Content identity is its cryptographic hash — derived from the content itself. The same content produces the same hash regardless of where it was created, stored, or served from. The hash is permanent. The location is not.

Content is defined by what it is, not where it lives. Any node holding a verified copy can serve it. The origin server is one source among many, not the single point of truth.

The hash as URL slug

The mechanism is almost aggressively simple. When content is published, its hash becomes its URL path on every host that carries it.

author.blog/AFC2D81
mirror1.blog/AFC2D81
mirror2.blog/AFC2D81
reader.cache/AFC2D81

The same hash, the same slug, on every node that holds the content. No search index. No distributed hash table. No gossip protocol. No consensus mechanism. The protocol is HTTP. The innovation is entirely in the addressing convention.

Verification without trust

The receiving device verifies two things independently: that the content received matches the hash requested, and that the content carries a valid cryptographic signature from the claimed author. Both checks are local. Neither requires trusting the serving node. A cached copy on an unknown node is exactly as trustworthy as the original, provided it passes verification.

Resolution Order

Local to remote,
stopping at the first answer.

Resolution proceeds from the requester outward, reflecting both efficiency and the consent model. Local sources are faster, cheaper, and require no external network activity.

01
Local Cache

The device checks its own storage first. If the content was previously pulled, cached by a nearby exchange, or received via proximity transfer, no network activity occurs at all.

02
Local Network

A multicast request to other devices on the same network. A desktop cached it, a phone wants it — local transfer without touching the internet.

03
Known Nodes

Subscribed blogs, bookmarked addresses, community servers. Standard HTTP requests targeted by hash slug. Any node that carries the content responds.

04
Origin Fallback

Direct pull from the original publisher. The guaranteed source — assuming origin is online. One source among many, not the authority. Unresolvable requests queue and retry rather than fail.

The resolution order is a client decision, not a protocol mandate. The protocol specifies the interaction format. The client decides the strategy.

What This Dissolves

Three problems that vanish by design.

01 / 03

Single Point of Failure

Deixis has no canonical URL. AFC2D81 is available wherever anyone who ever pulled it still has a copy. Taking down the origin server removes one source — it does not remove the content from every device that cached or forwarded it. There is no single point to attack because there is no single point of authority.

02 / 03

The Hosting Cost Curve

In conventional hosting, popularity is punished — a viral post costs the creator more bandwidth per reader. With Deixis, popularity inverts the cost curve. More readers means more cached copies, which means more sources for the next reader. Cost stays flat while reach grows.

03 / 03

Link Rot

A Deixis hash is permanent because it is derived from the content, not the host. An author who moves domains, changes providers, or loses their original server does not lose their content's addressability. Anyone who has the hash can still find the content from any node that holds it. Links do not rot.

Prior Art and the Unsolved Gap

The right idea, enclosed.

The insight that content identity should be intrinsic rather than locational has existed in computer science for decades. Git uses content-addressed storage internally. BitTorrent identifies files by hash. IPFS built an entire peer-to-peer network explicitly around content addressing as its primary design principle.

Each understood the right idea and then enclosed it in infrastructure that required adoption before it worked. The idea was right. The implementation kept it inside a walled garden.

BitTorrent and IPFS treated content addressing as a special-purpose system requiring special-purpose infrastructure. Deixis treats it as a convention that works on the existing web with zero additional infrastructure.

The gap Deixis fills is not technical. The gap is the assumption that content-addressed resolution requires a new network to run on. It does not. If the hash is the URL path, any HTTP server already participates. Any HTTP client already resolves. The existing web is the network. The convention is the entire protocol.

Summary

The complete specification.

The web is already the network. The hash is already the identifier. Deixis is the convention that connects them.