OmnimeshUK-developedDiscuss a requirement

02 / Platform overview

Secure transport software designed for application integration

The current design places Omnimesh in user space over UDP, integrated with the application environment and above the existing host network stack.

Discuss a requirement Review evaluation status

Deployment model

Secure transport software integrated with the application

Technical definitionApplication-integrated, user-space transport system carried over UDP.
Plain-English definitionSoftware-deployed secure transport—no host network-stack replacement required.

Operational fit

What changes—and what remains in place

The public design places Omnimesh at an application integration boundary while retaining the operating-system network stack and the wider security and connectivity estate.

What it is
An application-integrated transport system designed to execute in user space and be carried over UDP.
Where it fits
Within the application environment, above the existing operating system network stack and connectivity.
What it complements
Identity, endpoint, firewall, segmentation, cloud, application and data-security controls.
What it does not replace
The operating system network stack, wider security stack, security operations, identity governance or application-level protection.

Public system boundary

Designed to sit above the existing network stack

This public boundary shows the confirmed deployment model; packaging, operator ownership and detailed integration mechanics remain open.

Host environmentApplication integration required
ApplicationProtected workload
Application interface
User-space softwareOmnimeshTransport system carried over UDP
Uses existing interfaces
Retained foundationHost network stackNo replacement required
Existing connectivityIP network / third-party underlayNot controlled or trusted merely because traffic is encrypted
Peer environmentApplication endpointExact packaging and operator model remain under specification
Integration pointApplication environment
Execution modelUser space over UDP
Retained foundationExisting network stack and connectivity
Read technical note 01: system boundary and terminology

Evidence gates

Each design objective has a corresponding evidence requirement

Each row separates the intended purpose from the artefacts required to substantiate it.

Architecture specification

Integrated transport security

Design objective

Treat transport, path selection, encryption and trust boundaries as related system concerns.

Evidence gate

Documented architecture rationale, system boundary and implementation dependencies.

Protocol specification

Path-resilience design

Design objective

Reduce avoidable reliance on fixed or concentrated communication paths where the threat model justifies it.

Evidence gate

Measured failover behaviour, performance limits and adversarial test results.

Research track

Metadata-exposure research

Design objective

Investigate how transport design may reduce exposure of timing, path and relationship information.

Evidence gate

Defined threat model, metrics and measured results.

Assurance principle

Explicit trust boundaries

Design objective

Document dependencies, operators, failure behaviour and assumptions as part of the security model.

Evidence gate

Documented operators, dependencies, failure conditions and evaluation criteria.

Current boundaries

What Omnimesh does not currently claim

Universal protection against every observer, attack or disruption scenario.

Production readiness, government approval or critical-infrastructure assurance from design intent alone.

Anonymity, sovereign-grade assurance or nation-state resistance without defined criteria and evidence.

Technical investigation

Questions the detailed architecture must answer

Detailed architecture review will need to resolve the following questions before evaluation can advance.

Application interfaceUser-space lifecycleUDP and underlay modelRouting ownershipEncapsulationNAT and firewall traversalMTU and fragmentationLatency and throughputHigh availabilityTelemetryKey lifecycleFailure behaviourOperational ownership
Review the current evidence and evaluation path