A world model below the interface.
YuraNetwork is developing toward ecosystem protocols that connect environment, identity, network and services. Existing contracts are separated from proposals.
Who may participate?
Ownership, device identity and signed proof.
What may connect?
Native challenge, transport binding and session lifecycle.
What may be reached?
Private names, HTTPS trust and authorization.
Native admission / verified contract
The documented identifier is yura-native/1. An account-authenticated client registers a durable Ed25519 installation identity, proves possession, then binds an authorized admission challenge to the WireGuard transport key.
Trust boundary / message flow
Account session → registration challenge → Ed25519 proof → device credential → admission challenge → expiring Native session → heartbeat or revocation.
Private naming / service discovery
Native provides private transport. Private DNS resolves .yura names inside that environment, while HTTPS verification and application authorization remain separate checks.
Publication / lifecycle direction
Studio and hosting direction connects account-owned source, preview, immutable versions, access policy, publication and rollback. Future managed lifecycle is not confused with current static capability.
YuraCore coordination / design direction
A future coordination vocabulary can expose readiness, identity context, service relationships and recovery state to YuraShell and applications. This is not a deployed public API.
Protocol research / next layer
The long-term direction explores identity-aware discovery, cross-application context, publishing messages and system-to-service coordination with explicit versioning and failure semantics.
“Verified contract” refers to documented behavior. “Design direction” is a proposal, not a deployed standard or security certification.