Authenticated private names and signed service records.
YNP is a proposed naming direction for the private .yura ecosystem. It would connect a human-readable name to signed service and ownership records without treating DNS reachability as ownership proof. The existing .yura resolver remains operational and is not replaced by YNP.
YuraMesh v0.4 is a coordination specification. Native v1 remains operational and authoritative. YuraMesh production implementation is not authorized.
YNP — Yura Name Protocol belongs to a larger control plane.
YNP would need canonical records, authenticated responses, name ownership, expiry, sequence and revocation semantics. Its value is a verifiable relationship between a name, an Anchor and a service—not merely a lookup result.
Its authority is intentionally bounded: identity, transport, naming, discovery, ownership and data protection are related without becoming interchangeable.
Input state
Explicit identity, record or transport context enters the component.
YNP — Yura Name Protocol
Name → signed record → verified service
Scoped next state
Only the authority and lifecycle signal defined by the design may continue.
Name → signed record → verified service
A resolver response is useful only when its authority, sequence and expiry can be checked. YNP therefore belongs between a human-readable private name and the ownership/service records that give the name meaning. The current .yura DNS path remains a separate operational system.
That boundary is the reason this component is named separately: it can evolve, be reviewed and be revoked without silently granting unrelated powers to the rest of the ecosystem.
Evidence status
Grounded in YuraMesh protocol specifications and phase-one audit material found in the authorized workspace. This page describes a specified or proposed architecture, not a claim of production deployment.
Trust boundary
Implementations must verify signatures, scope, expiry, replay, sequence and revocation according to the applicable specification. Reachability, DNS, TLS or Native success alone cannot establish the authority described here.
Relationship to current YuraNetwork
Native v1 remains unchanged and authoritative. Any future adapter must preserve its transcript and be separately reviewed. YuraCore may eventually expose lifecycle and readiness context through defined interfaces; that interface is not yet a public production API.