YuraNetwork
Home / Architecture / Y11
Architecture / Y11

Y11 — The YuraNetwork 11-Layer Architecture

Eleven architectural domains connecting the operating environment, private network, identity, trust, ownership, services and applications.

PROPOSED REFERENCE ARCHITECTURE V0.2

Y11 complements OSI and established networking; it does not replace them.

Canonical visual model

A system architecture, not a packet stack.

Y11 organizes the operating environment, identity-aware network participation, trust, private discovery, ownership, services and experience into one studyable model.

YuraNetwork Y11 reference architecture posterA technical isometric-style architecture model with eleven numbered Y11 platforms, domain groups on the left, YuraMesh components on the right, and labeled cross-layer relationship paths.YURANETWORK / REFERENCE ARCHITECTUREY11 — ELEVEN ARCHITECTURAL DOMAINSARCHITECTURAL DOMAINSEXPERIENCE / COORDINATIONSERVICES / OWNERSHIPDISCOVERY / MEMBERSHIPTRUST / IDENTITYTRANSPORT / CONNECTIVITYFOUNDATIONL11Experience LayerHuman-facing interface to YuraNetwork.L10Coordination LayerCoordinate verified system, service and application state.L9Services LayerDeliver websites, applications and digital services.L8Ownership LayerEstablish ownership, delegation, authorization and lifecycle authority.L7Discovery LayerResolve and discover private YuraNetwork services.L6Membership LayerRepresent authorized participation in the private environment.L5Trust LayerEvaluate whether identities, devices and operations meet participation conditions.L4Identity LayerMaintain distinct cryptographic identities for participants and resources.L3Transport LayerCarry protected communication between participating systems.L2Connectivity LayerProvide access to underlying communications infrastructure.L1Foundation LayerProvide hardware and operating-system capabilities.DEPENDENCY PATHCROSS-LAYERYURAMESH / DESIGN FAMILYYNPVEILYuraGenesisYuraAnchorYuraObscuraYuraVaultYuraContinuumYuraSeveranceYuraSpectreNative v1 remains currentoperational architecture.YuraMesh is specified orproposed, not a live status feed.layer responsibilitycross-layer design relationshipillustrative architecture path
Canonical visual model: eleven Y11 responsibilities are shown as an isometric architectural structure. The left domain rail groups related responsibilities without granting exclusive control; the right rail maps the named YuraMesh family across documented layers. Every path is a relationship or dependency, not a literal packet sequence.
Current operational referenceSpecified or proposed relationshipTrust or responsibility boundaryCross-layer dependency path
Open the vector reference poster ↗
Why Y11 exists

One architecture.
Many responsibilities.

Y11 maps the operating environment, connectivity, protected transport, identity, trust, membership, discovery, ownership, services, coordination and experience.

It is a layered reference architecture, not a linear packet stack. Identity, ownership and coordination cross boundaries; each enforcing service remains responsible for its own policy.

L11

Experience Layer

Human-facing interface to YuraNetwork.

YuraNetwork OS, YuraShell, YuraBrowser, YuraSearch, Studio, first-party applications
L10

Coordination Layer

Coordinate verified system, service and application state.

YuraCore
L9

Services Layer

Deliver websites, applications and digital services.

Studio publication, self-hosting, managed hosting direction, APIs, workers, storage
L8

Ownership Layer

Establish ownership, delegation, authorization and lifecycle authority.

Account-owned resources, YuraAnchor, YuraSeverance
L7

Discovery Layer

Resolve and discover private YuraNetwork services.

Private .yura DNS, YNP, YuraBrowser, YuraSearch, YuraObscura
L6

Membership Layer

Represent authorized participation in the private environment.

Native membership, private addressing, peer lifecycle, private routing
L5

Trust Layer

Evaluate whether identities, devices and operations meet participation conditions.

Native admission, VEIL
L4

Identity Layer

Maintain distinct cryptographic identities for participants and resources.

Installation identity, device/session identity, ownership identity, YuraGenesis
L3

Transport Layer

Carry protected communication between participating systems.

WireGuard, Native transport binding, YuraSpectre
L2

Connectivity Layer

Provide access to underlying communications infrastructure.

Ethernet, Wi-Fi, network interfaces, public Internet, underlay addressing
L1

Foundation Layer

Provide hardware and operating-system capabilities.

Hardware, Linux kernel foundation, processes, permissions, filesystems, storage, system services

Select a layer to focus its explanation. The stack is a reference view, not sequential packet processing.

Layer explorer

Responsibilities, boundaries and future work.

Every layer records its purpose, interfaces, dependencies, current evidence, future direction, trust boundary, failure behavior and engineering prerequisites.

L11 Experience Layer

Purpose

Human-facing interface to YuraNetwork.

Components

YuraNetwork OS, YuraShell, YuraBrowser, YuraSearch, Studio, first-party applications

Dependencies

L10 coordination; L9 services; L7 discovery

Current implementation

Product pages and existing application surfaces

Future direction

Future YuraGram integration

Interface

Consumes user intents and authenticated state; emits user actions and presentation state.

Trust boundary

May display verified state but cannot invent identity, membership or authorization.

Failure behavior

Unavailable applications should fail closed, preserve drafts where supported and explain the responsible lower-layer condition.

Engineering requirements

Accessible state presentation, explicit authorization results, keyboard navigation, safe action mapping, session boundaries and no privileged decision-making in the UI.

L10 Coordination Layer

Purpose

Coordinate verified system, service and application state.

Components

YuraCore

Dependencies

L1-L9 authenticated status sources; L11 presentation

Current implementation

Readiness and state-coordination architecture

Future direction

YuraMesh lifecycle-event interfaces

Interface

Aggregates authenticated status signals into typed readiness, reconciliation and recovery context.

Trust boundary

Consumes authenticated signals; enforcement remains with the responsible service and policy owner.

Failure behavior

Stale or conflicting state must be marked unknown, not converted into access or health claims.

Engineering requirements

Typed state model, provenance, freshness, reconciliation rules, error taxonomy, recovery context, least privilege and audit events.

L9 Services Layer

Purpose

Deliver websites, applications and digital services.

Components

Studio publication, self-hosting, managed hosting direction, APIs, workers, storage

Dependencies

L8 ownership; L7 discovery; L6 membership; L10 coordination

Current implementation

Static/self-hosted workflows; Studio staging contracts

Future direction

Isolated managed dynamic services; YuraVault and YuraContinuum integration

Interface

Accepts authorized deployment operations and returns version, health, endpoint and lifecycle state.

Trust boundary

Separates deployment state, service identity, hosting location and application authorization.

Failure behavior

Failed deployment must not become active; rollback, retention and unavailable-service state must be explicit.

Engineering requirements

Artifact validation, immutable versions, isolation, secret boundaries, lifecycle state, rollback, backups, health checks and recovery tests.

L8 Ownership Layer

Purpose

Establish ownership, delegation, authorization and lifecycle authority.

Components

Account-owned resources, YuraAnchor, YuraSeverance

Dependencies

L4 identity; L5 trust; L7 discovery; L9 services

Current implementation

Account-scoped project and access concepts

Future direction

Signed portable ownership and retirement

Interface

Accepts ownership proofs and scoped operations; emits signed ownership, delegation, revocation or retirement state.

Trust boundary

Ownership authority must be proven separately from reachability, device identity and hosting location.

Failure behavior

Invalid, expired or conflicting authority must block publication or state transition and preserve prior valid state.

Engineering requirements

Canonical owner identity, signature verification, sequence/expiry, delegation scope, revocation, anti-rollback and governance.

L7 Discovery Layer

Purpose

Resolve and discover private YuraNetwork services.

Components

Private .yura DNS, YNP, YuraBrowser, YuraSearch, YuraObscura

Dependencies

L6 membership; L8 ownership; L9 service state

Current implementation

Private .yura resolution and private search surfaces

Future direction

Authenticated names, signed records and capability-aware discovery

Interface

Maps a name or query to service records, Presence and capability information with freshness metadata.

Trust boundary

A lookup, endpoint or Presence record is not ownership, host integrity or access authorization.

Failure behavior

Expired, revoked or inconsistent records must be marked unknown or rejected according to the applicable contract.

Engineering requirements

Canonical names, authenticated records, freshness, sequence, revocation, cache rules, privacy boundaries and resolver conformance tests.

L6 Membership Layer

Purpose

Represent authorized participation in the private environment.

Components

Native membership, private addressing, peer lifecycle, private routing

Dependencies

L3 transport; L4 identity; L5 trust; L2 connectivity

Current implementation

Native admission and WireGuard peer lifecycle

Future direction

YuraMesh membership extensions

Interface

Binds an admitted device to private addressing, peer state and route eligibility.

Trust boundary

Membership is distinct from identity and from application permission.

Failure behavior

Expired or revoked membership removes eligibility and must propagate to peers and routes without granting fallback access.

Engineering requirements

Membership state, expiry, revocation propagation, peer reconciliation, split-routing rules, address lifecycle and recovery.

L5 Trust Layer

Purpose

Evaluate whether identities, devices and operations meet participation conditions.

Components

Native admission, VEIL

Dependencies

L4 identity; L6 membership; account policy

Current implementation

Signed Native admission contract

Future direction

VEIL scoped membership and layered admission

Interface

Verifies proofs, scope, expiry and policy before issuing or accepting an admission decision.

Trust boundary

Authentication proves control of credentials; authorization, scope and policy remain separate decisions.

Failure behavior

Invalid proof, replay, expiry, scope escalation or revoked authority must fail closed and be observable without leaking secrets.

Engineering requirements

Challenge binding, replay resistance, scoped credentials, expiry, revocation, delegation rules, clock handling and negative tests.

L4 Identity Layer

Purpose

Maintain distinct cryptographic identities for participants and resources.

Components

Installation identity, device/session identity, ownership identity, YuraGenesis

Dependencies

L1 foundation; account relationship; L5 trust; L8 ownership

Current implementation

Ed25519 Native installation/device identity

Future direction

Role-separated identity and recovery architecture

Interface

Creates, stores, rotates and revokes role-specific identifiers and public-key relationships.

Trust boundary

A key proves control of a key; it does not automatically prove every authority or anonymity.

Failure behavior

Lost, compromised or ambiguous identity must trigger scoped recovery or revocation rather than silent reassignment.

Engineering requirements

Key roles, storage boundaries, rotation, recovery, revocation, correlation limits, device binding and test fixtures.

L3 Transport Layer

Purpose

Carry protected communication between participating systems.

Components

WireGuard, Native transport binding, YuraSpectre

Dependencies

L2 connectivity; L4 identity; L5 trust; L6 membership

Current implementation

WireGuard-based Native transport

Future direction

Authenticated privacy-conscious transport research

Interface

Carries encrypted packets between authorized endpoints and reports transport/session state.

Trust boundary

Encryption protects transport properties; it does not establish service authorization or anonymity.

Failure behavior

Handshake loss, route failure or relay failure must be visible as transport failure without being misreported as identity failure.

Engineering requirements

Key binding, endpoint policy, replay protection from underlying protocol, route lifecycle, observability and threat-model evaluation.

L2 Connectivity Layer

Purpose

Provide access to underlying communications infrastructure.

Components

Ethernet, Wi-Fi, network interfaces, public Internet, underlay addressing

Dependencies

Hardware and OS foundation

Current implementation

Existing physical and public network interfaces

Future direction

Better transition and readiness reporting

Interface

Reports link, interface, address and reachability conditions to transport and coordination layers.

Trust boundary

Link availability is not Native readiness, private membership or service authorization.

Failure behavior

Interface changes, captive portals, loss of route or address changes must trigger reconnection and stale-state handling.

Engineering requirements

Interface detection, route transitions, DNS boundary handling, timeout policy and recovery testing across network changes.

L1 Foundation Layer

Purpose

Provide hardware and operating-system capabilities.

Components

Hardware, Linux kernel foundation, processes, permissions, filesystems, storage, system services

Dependencies

Hardware and boot environment

Current implementation

Linux kernel and established OS components

Future direction

YuraNetwork OS integration and verified release capabilities

Interface

Provides process, memory, permission, storage, device and kernel-networking primitives to higher layers.

Trust boundary

Foundational mechanisms must be configured and verified; the kernel alone is not a privacy guarantee.

Failure behavior

Boot, storage, process, permission or device failure must preserve recovery paths and avoid claiming higher-layer readiness.

Engineering requirements

Supported hardware matrix, privilege boundaries, storage/encryption configuration, startup ordering, recovery and release-specific verification.

Cross-layer workflows

Architecture becomes useful in motion.

These sequences distinguish current Native and service behavior from proposed YuraMesh extensions.

WORKFLOW 01

Entering YuraNetwork

  1. Foundation and connectivity establish the device and underlay route.
  2. Native v1 verifies admission and binds the admitted device to WireGuard transport.
  3. Membership and private addressing remain distinct from the device key and route eligibility.
  4. YuraCore can present readiness and recovery context to YuraShell; services still enforce policy.
  5. Future YuraMesh extensions may add VEIL, YuraGenesis and lifecycle events; these are not claimed as deployed.
WORKFLOW 02

Opening a private .yura website

  1. YuraBrowser receives the navigation intent; the interface is not an authorization decision.
  2. Current private DNS resolves the name and private HTTPS provides the expected trust boundary.
  3. Native membership and transport make the route reachable, but reachability is not application permission.
  4. The service applies its own authentication and authorization before returning content.
  5. Proposed YNP, YuraAnchor and YuraObscura designs could add signed records, portable ownership and capability-aware discovery.
WORKFLOW 03

Publishing through Studio

  1. An owner creates or imports a project and prepares a versioned artifact using the current workflow.
  2. Preview and validation separate a candidate from an active deployment.
  3. Ownership, hosting location, name association and service state remain distinct.
  4. A publication operation should report version, endpoint, health, rollback and discovery state.
  5. Future YuraAnchor, YuraVault, YuraContinuum and YuraSeverance designs could extend ownership, protected objects, migration and retirement.
WORKFLOW 04

Revoking a device or service

  1. Identify the affected principal and authority; possession of a key is not universal authority.
  2. Revoke or expire admission or membership, then reconcile peer and route eligibility.
  3. Separately remove service authorization or retire a website identity; these are different operations.
  4. Propagate state to discovery and coordination without treating stale cache data as availability proof.
  5. Future VEIL, YuraGenesis, YNP and YuraSeverance contracts must define scope, ordering, expiry, replay and recovery.
WORKFLOW 05

Moving a website between hosts

  1. Keep website identity and ownership authority distinct from hosting location.
  2. Prepare and validate the destination before changing active service records.
  3. A proposed YuraAnchor statement could authorize the move; YNP could publish a fresh record.
  4. YuraContinuum is the proposed continuity direction for rotation, migration, delegation and recovery.
  5. Retire stale advertisements only after verification; this is not universally operational today.
YuraMesh mapping

Nine named components cross boundaries.

No component is forced into one layer: protocol responsibilities interact with identity, trust, discovery, ownership, services and transport.

Y11 and OSI

Complementary models.

OSI is a seven-layer networking reference model. Y11 is a proposed YuraNetwork ecosystem architecture that includes responsibilities beyond packet communication.

OSI 01

Physical

OSI purpose: Signals, media and physical transmission.

Y11 relationship: Y11 L1 Foundation and L2 Connectivity describe the operating and underlay foundations, not a replacement for physical standards.

OSI 02

Data Link

OSI purpose: Local framing, addressing and link delivery.

Y11 relationship: Y11 L2 observes interface and link conditions; it does not redefine Ethernet or Wi-Fi.

OSI 03

Network

OSI purpose: Logical addressing and packet forwarding.

Y11 relationship: Y11 L2 and L6 cover connectivity, private membership and route eligibility across established mechanisms.

OSI 04

Transport

OSI purpose: End-to-end delivery characteristics.

Y11 relationship: Y11 L3 describes protected transport such as current WireGuard-based Native transport and future research.

OSI 05

Session

OSI purpose: Conversation establishment and continuity.

Y11 relationship: Y11 distributes session state across L3-L6, L10 coordination and application contracts.

OSI 06

Presentation

OSI purpose: Representation, encoding and transformation.

Y11 relationship: Y11 has no one-to-one equivalent; schemas, certificates, UI and service contracts cross L7-L11.

OSI 07

Application

OSI purpose: User-facing network applications.

Y11 relationship: Y11 L9-L11 cover services, coordination and experience while also adding identity, ownership and trust domains below them.

Why there is no one-to-one mapping

OSI organizes communication functions. Y11 also describes identity, trust, membership, ownership, services and coordination. A workflow can cross several Y11 domains without executing them in numeric order, and one protocol can touch several domains.

Current versus proposed

Native v1, WireGuard, private addressing, private DNS, private HTTPS, current Studio material and existing product surfaces are operational reference points. YuraMesh components remain specified or proposed and require contracts, implementation and validation.

Canonical project knowledge

YURANETWORK_Y11_REFERENCE_ARCHITECTURE_V0.1.md remains preserved. The synchronized v0.2 Markdown and JSON files record this content expansion without overwriting historical material.

Engineering discipline

Future work must define typed state, authentication rules, schemas, versioning, expiry, replay protection, revocation, key rotation, recovery, audit events, compatibility, migration, test vectors and conformance tests before proposed behavior is called operational.

YuraMesh hub Protocol directory Documentation