Client-controlled encrypted objects.
Vault is the planned encrypted-data architecture. The v0.4 direction uses object manifests, fresh object keys, XChaCha20-Poly1305-IETF payload protection and standards-based recipient wrapping directions.
YuraMesh v0.4 is a coordination specification. Native v1 remains operational and authoritative. YuraMesh production implementation is not authorized.
YuraVault belongs to a larger control plane.
The VPS would see ciphertext, manifests, timing and routing metadata, not owner plaintext keys. This does not hide metadata or protect compromised authorized endpoints. Profiles, library versions, recovery parameters and interoperability fixtures remain provisional.
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.
YuraVault
Plaintext on client → encrypted object → authorized recipient
Scoped next state
Only the authority and lifecycle signal defined by the design may continue.
Plaintext on client → encrypted object → authorized recipient
Vault puts object protection at the client boundary. Fresh object keys and recipient wrapping are designed to keep storage useful without making the storage provider the holder of owner plaintext keys. Metadata and endpoint compromise remain explicit limitations.
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.