Share the Name, Not the Bits

A URL is a promise about a location. It says: go here, and the thing you want will be there. Every time you've shared one, you've made that promise on behalf of infrastructure that moves — and every redeploy, region migration, and domain change quietly breaks it. The link in your runbook, your agent's config, your partner's integration doc: pointing at where the thing used to be.

We just stopped making that promise. Resources protected by qURL™ now get a CRID — a Cryptographic Resource ID. Sixty lowercase characters that name the resource itself, not the place it happens to be running today.

ae4jqpd7eaoslq7jinmjv4yikgzmcxgpjfsuobiniqnko32lpw743ivbeyha

That's not a link. It doesn't take you anywhere. It's a name — and that's the point.

URLs tell you where to go and make you trust a certificate authority. CRIDs tell you what you're getting and let you trust no one but the math.

A name, not a secret#

A CRID is derived from the resource's public key: a version byte, a domain-separated SHA-256 hash of the key, and a checksum, base32-encoded into sixty lowercase characters. If that construction sounds familiar, it should — it's the same shape as a Bitcoin address. Version, hash of a key, checksum. A format designed to be pasted into chats, printed on paper, and read over the phone, by people who assume everyone is listening.

So treat it that way. Put a CRID in your docs, your source code, your MCP config, a Slack channel, a support ticket. It is safe everywhere, because holding it grants nothing. There is no access to leak — a CRID is the resource's name, and access still requires a credential your identity provider vouches for.

And when the resource's owner — or an agent holding the owner's credential — needs access now, the name becomes access in one call: POST /v1/resources/{id}/share takes a CRID and mints a fresh, short-lived qURL access link — the disappearing kind we've always issued. The link is the secret, scoped and expiring, minted per-moment for one holder. The CRID is the name you keep.

Share the name, not the bits.

It never moves, because it isn't anywhere#

A CRID commits to the resource's key, not its coordinates. Redeploy the resource, move it across regions or clouds, put it behind a different domain — the CRID doesn't change, because nothing it's derived from changed. The name in the runbook you wrote today still names the same resource after every migration between now and the day you delete it.

And when you do delete it, the name dies with it. A retired CRID is never re-minted and never points at anything else — nobody inherits your name the way they can inherit your expired domain, your recycled S3 bucket, or your old IP. A CRID has exactly one referent, forever. Dangling references fail closed instead of resolving to whoever moved in after you.

Verified by math, not by a middleman#

Here's the property we care about most. When infrastructure delivers a public key for a CRID you hold, you don't have to trust the channel that delivered it — or the platform behind it. Hash the delivered key, compare against the name. Match: it's the committed key. Mismatch: reject. No certificate authority in the loop, no trust store to maintain, and nothing to take on faith from us. A CRID makes key substitution detectable by arithmetic — which means our own relay couldn't hand you a swapped key without your client catching it. We think the access layer should be built so its operator doesn't have to be trusted on this, and now it is.

The checksum, meanwhile, is doing humbler work: it catches typos and truncation before anything touches the network, the way an address checksum stops you from sending funds into the void. It's a convenience, not the security — the hash is the security.

None of this asks you to take our word for it. The full derivation is pinned by public, cross-language conformance vectors — qurl-crid-v1-vectors in layervai/qurl-conformance — so an independent implementation in any language can prove, byte for byte, that it derives and validates CRIDs exactly as the platform does. Every intermediate value is in the fixtures. Check our math; that's what it's for.

Live today#

CRID is live now on the qURL API:

• Resource responses now carry a crid field.
• Every endpoint that takes a resource ID accepts the CRID interchangeably with the public-key resource ID — same resource, two spellings of its identity.
• POST /v1/resources/{id}/share turns a CRID into a fresh short-lived access link, for the resource's owner.

You can even tell environments apart at a glance: production CRIDs start with a; the names you mint in your sandbox start with q. The name itself says which environment it came from, so a sandbox name can never be mistaken for a production one — not by you, not by a script, not by an agent.

What a CRID is not#

We build access infrastructure, so let's be precise about the claim. A CRID is identity and provenance — a permanent name with a built-in authenticity check. It is not access control: minting a qURL from a CRID still requires an authorized credential, same as ever. It is not DRM: it does nothing to what recipients do with delivered content. And it doesn't remove the relay from your path — qURL still operates the rendezvous your traffic crosses. What it removes is any need to trust that rendezvous about whose key you're holding. That's the honest scope: names you can share with anyone, verified by no one.

Take the Next Step#

• Read the API reference — the crid field, dual-accept addressing, and share
• Install the qURL CLI — publish a resource and share a private link in minutes, free
• Read how qURL works — invisible by default, access that disappears
• Check our math — the public conformance vectors

---

The location is temporary. The name is forever.