Runtime Layers

Capability handles above one shared Rust native and WASM runtime

Public application layer

Most products use OpenRTC({ apiKey }) and activate devices, spaces, rooms, or tickets. Handles own their lifecycle and expose peer, channel, and diagnostic views.

The root client does not extend the low-level runtime. This prevents application code from accidentally creating a second lifecycle owner.

Shared Rust core

Browser WASM and native/Tauri use the same Rust connection engine, transport policy, admission state, device identity semantics, and peer-session ownership. The native host stores the per-install signing key in host secure storage; supported browsers use a non-extractable WebCrypto key backed by IndexedDB.

The TypeScript layer owns the developer-facing capability API. It lazily loads the runtime only when a handle starts, exchanges identity or capability proof with the control plane, and refreshes a grant in place without replacing a healthy peer session.

In a browser, that API loads the Rust core compiled to WASM. In Tauri, the openrtc/native entrypoint projects the same public API over IPC to one native Rust Client; it does not load WASM or create a second lifecycle owner. A pure Rust application can use the crate directly without TypeScript or IPC.

Low-level entrypoint

openrtc/runtime is for runtime adapters and specialized protocol integration. It is not the normal application interface and is not inherited by Client.

Specialized semantics belong in extension packages:

  • openrtc-netcode: matches and replicated/latest state
  • openrtc-file-transfer: transfer bounds, acknowledgements, and recovery
  • y-openrtc: Yjs provider over one activated room