qURL 2.0: Infrastructure Without Exposure

Putting something online has usually meant giving it a place that strangers can reach. We publish an address, put authentication in front of it, and defend that entrance for as long as the service exists.

That arrangement has become so familiar that we treat public reachability as a requirement for useful connectivity. It isn't.

Today, we're introducing qURL™ 2.0: the September platform release that brings a permanent resource identity, temporary access, and network invisibility into one system. It is the result of months of work across the protocol, platform, Connectors, and developer tools. The change is larger than a new link format. It gives builders a different starting point: make a resource useful without making it a standing public target.

Three things that no longer need to be one#

An address, an identity, and permission to connect solve different problems. qURL 2.0 lets you manage them separately.

• CRID is the name you keep. A Cryptographic Resource ID identifies a resource through its public key. It stays stable when the resource moves, as long as that key stays the same. Knowing the name does not grant access.
• A qURL is the access you grant. Create a link with its own lifetime and access rules. Create another for a different task. Revoke a link without replacing the resource's identity or every other link.
• Invisibility is the default network state. A correctly protected resource does not offer an unauthenticated public entry point. An approved request opens the access path it needs.

A permanent name. Temporary access. An invisible resource. These are the building blocks of a new access model.

Read the qURL 2.0 release notes for the shipped capabilities and developer guidance.

CRIDs change what a resource name can mean#

A conventional URL tells a client where to go. A CRID gives the client a stable commitment to a resource's public key.

That distinction matters when infrastructure moves. A deployment can change its location without changing the identity that an integration holds. It also matters when a client receives a key: the client can derive the CRID from that key and compare it with the name it already trusts. A different key produces a different name.

The comparison does not need a certificate authority to certify the name-to-key relationship. It is a local calculation that independent implementations can check against public test vectors. The first trusted CRID still needs to come from a trusted source; the math then checks the key against it.

This is why we see CRIDs as a primitive, not a convenience field. They let software carry a durable reference without carrying an access credential or hard-coding the resource's current location. A runbook, a partner integration, and an agent's configuration can refer to the same resource while access changes around it.

Share the Name, Not the Bits explains the construction, the trust boundary, and what a CRID can verify.

Invisibility changes the starting condition#

Most security controls decide what to do with traffic after it reaches an application or its public front door. Network hiding changes whether an unauthorized caller can reach the protected service in the first place.

LayerV builds on OpenNHP to verify requests before opening the protected access path. A Connector sits beside the resource and connects it to the platform. The application can stay where it runs today; builders do not need to rewrite it to use a different access model.

“Invisible” has a specific meaning here: the protected origin is not available for unauthenticated public connections. LayerV's public access infrastructure still exists. You must close any alternate public route to the origin. Application authentication and secure application code still matter once access is granted.

The strategic change is the default. A private API, an internal tool, or a development service can be available to its intended users without remaining available for everyone else's connection attempts.

Built for people and agents#

People need access they can use. Agents need access they can request and manage through software. Both need boundaries that survive the end of a task.

Consider a private reporting service. Its owner keeps the CRID as the stable reference. A colleague receives a qURL for a review. An authorized automation creates a separate link for a scheduled job. The links can have different rules and lifetimes. Closing one grant does not require renaming the service.

For a person, the entry point is a link and the verification that its rules require. For an agent, the API, CLI, SDKs, and MCP integration provide programmatic tools. An agent still needs authorized credentials. Learning a CRID is not a way around permission checks.

This makes access something software can manage as part of a task: identify the resource, request the allowed access, do the work, and let that access expire or revoke it. Builders can design around the task instead of handing every integration a permanent network entrance.

A platform release, from identity to everyday use#

qURL 2.0 brings together resource identity, signed access links, individual link management, Connector-based publishing, and access for browser and native clients. The accompanying CLI and SDK releases make that foundation easier to use in production.

The value comes from the parts working together. A stable name alone does not protect a service. An expiring link alone does not remove a public origin. Network hiding alone does not give an agent a durable reference. Together, they let builders separate what a resource is, where it runs, and who can reach it now.

That is the opportunity we are building toward: an internet where useful resources do not need permanent public exposure, and where access for people and agents can be explicit, limited, and part of the application workflow.

Next: carry identity into the response#

The next step we are working toward is response-content verification: let a client check that the bytes it received were signed by the producer associated with the resource's CRID.

Today, the CRID gives the client a way to check the resource key. The future step is to use that verified identity to check a signature over the response itself. For an agent acting on private data, that would connect “which resource did I intend to use?” with “did this response come from that resource, unchanged?”

This is a forward-looking direction, not a capability shipped in qURL 2.0. It would establish origin and integrity, not whether the information is factually correct. The significance is the foundation: a stable cryptographic identity can support more than finding a resource. It can support verifying what the resource delivers.

Put it to work#

Start with one private app or API. Publish it through a Connector, create a qURL, and follow the recipient's path. Then try a second link with a different lifetime and revoke the first.

• Start building — protect and share your first resource.
• Understand CRIDs — learn why identity can stay stable while access changes.
• Read the release notes — see the capabilities and integration details.
• Talk with LayerV — discuss the platform and what it enables for your team.

Keep the identity. Grant the access. Remove the exposure.