Skip to main content

​
Do you need an app server?

An app server is only required if you encrypt content. If you serve public blobs, the CDN delivers them directly and you don’t need any external component — just origin-backed nodes and a catalog. You need an app server if you need:
  • Subscription or entitlement gating (only paying users can play)
  • Time-bounded access (lease / rental windows)
  • Geographic / contractual restrictions
  • Per-user access revocation mid-session
  • Offline playback leases

​
What the app server does

  1. Stores blob encryption keys (K_blob) received from your ingest pipeline.
  2. Authenticates client sessions (your existing OAuth / session token stack).
  3. On each play request, wraps K_blob with the current epoch key and sends the envelope over an authenticated cdn/keys/v1 QUIC stream to the client.
  4. Rotates the epoch key every 5 minutes.
  5. Closes the epoch key stream to revoke access within one epoch.
CDN nodes only ever see ciphertext. They have no knowledge of K_blob or your epoch keys.

​
What the app server does not do

  • Does not participate in gossip, probing, or staking — it is not a CDN protocol participant.
  • Does not deliver content bytes — CDN nodes do that.
  • Does not bill for bandwidth — clients pay nodes directly for bandwidth; you bill clients for entitlement through your existing subscription infrastructure.

​
Transport: why iroh QUIC?

The app server shares iroh QUIC transport with the CDN but uses a different ALPN (cdn/keys/v1). Key delivery is tightly coupled to the client’s iroh identity — the QUIC handshake provides mutual authentication (client NodeId ↔ app server NodeId) and TLS 1.3 confidentiality in a single step, eliminating the need for crypto_box_seal + X25519 key management. Your clients run a single transport stack for both CDN delivery and key delivery.

​
Scaling

One iroh QUIC connection per active subscriber. Standard QUIC server scaling applies: connection migration, load-balancer affinity, graceful shutdown. The app server scales with your subscriber count, not with CDN node count. A subscriber does not typically maintain the cdn/keys/v1 connection idle — it opens it on play, receives the envelope, and lets it idle or close. The steady-state connection count is much lower than peak-play-simultaneity.

​
Reference implementation

A reference implementation is published as a separate repository. The CDN crates do not depend on it — you integrate an iroh::Endpoint accepting cdn/keys/v1 connections alongside your existing auth/billing stack.

​
Deployment posture

Typical production deployment:
  • N app server instances behind a load balancer, each running iroh QUIC.
  • Shared key store (Redis, hashicorp Vault, or AWS KMS) for K_blob material.
  • Subscription DB — your existing billing/entitlements database.
  • Observability — standard QUIC server metrics plus per-subscriber auth/play logs.

​
Security posture

  • App server compromise = all content exposed. K_blob keys are long-lived in the key store. Treat this host as highest-sensitivity infrastructure.
  • Epoch key rotation limits access-control blast radius (a compromised epoch key only affects the next ≤5 minutes) but does not provide forward secrecy for stored K_blob.
  • Forward secrecy for epoch keys comes from the 5-minute rotation — a compromised epoch key cannot decrypt past envelopes held by other clients. Forward secrecy for stored K_blob is a separate open item.

​
What you still own

  • Your subscription billing system.
  • Your OAuth / session token infrastructure.
  • Your entitlements logic (who can play what).
  • Your offline lease semantics.
deCDN’s app server interface is the hand-off point between your existing auth stack and the CDN’s key delivery path. Everything above the hand-off is your product. See encryption setup for the underlying key hierarchy.