Architecture

Provider-neutral control plane, edge admission, and shared Rust runtime

OpenRTC separates product identity, durable control data, live coordination, and peer payload.

consumer auth or capability proof
  -> OpenRTC control plane
  -> device certificate + scoped gateway grant
  -> Cloudflare Worker admission
  -> one Durable Object per active avenue
  -> Rust native/WASM peer session
  -> direct Iroh/WebRTC payload, with bounded relay fallback

Ownership

  • The consumer owns login UX, product authorization, identity-provider configuration, and platform-attestation registration.
  • The OpenRTC control plane validates assertions/evidence, binds device keys, applies revocation, issues scoped grants, and enforces budgets.
  • The Cloudflare gateway validates grants locally and owns live avenue presence/signaling. It does not call Firebase during socket admission.
  • One Durable Object owns each active avenue. Presence changes on connect, meaningful state change, disconnect, or server expiry—never a client heartbeat loop.
  • Rust owns peer-session admission and physical transport state for both native and WASM.
  • Application protocols own their own message meaning; core OpenRTC remains message-agnostic.

Usage and abuse boundary

Origin, device signature, nonce, replay, manifest, rate, and budget checks happen before Durable Object creation. Usage reservations remain in place while settlement is pending, and retries settle the originating operation rather than recursively creating billing events.

Direct peer payload is not charged per application message. Relay bytes and opted-in managed services are measured separately.

Provider neutrality

Firebase currently stores durable control-plane state and billing records. Cloudflare Workers and Durable Objects own live coordination. Neither provider appears in the public constructor or capability protocol, so implementations can move without changing consumer application semantics.