// the take
The official browser-side TypeScript SDK for LiveKit, handling WebRTC signaling, track publishing/subscription, and data channels against a LiveKit Cloud or self-hosted server. It's for teams building video calling, live streaming, or voice-agent frontends who don't want to hand-roll WebRTC signaling and SFU negotiation themselves.
E2EE is implemented properly via Insertable Streams with a dedicated worker doing frame-level AES-GCM encryption (FrameCryptor, ParticipantKeyHandler) rather than bolted on as an afterthought. AdaptiveStream and dynacast give real bandwidth/CPU savings by only subscribing to tracks that are actually visible and adjusting published encodings accordingly. The data layer is unusually complete for a media SDK — reliable and lossy data channels, chunked data streams with compression, and a packetizer/depacketizer for custom data tracks. Test coverage is genuinely broad, including an e2e signal client test and race-condition tests on the frame cryptor, not just unit stubs.
You're buying into the LiveKit server protocol specifically — this isn't a generic WebRTC wrapper, so there's no path to point it at an arbitrary SFU. The built-in token generation (TokenSource.developmentTokenServer) is explicitly called out as insecure and prototyping-only, meaning production use requires you to stand up and secure your own token endpoint from day one. Browser audio autoplay policies push real UI work onto the consumer (RoomEvent.AudioPlaybackStatusChanged plus a manual startAudio() call bound to a user gesture) — not LiveKit's fault, but it's friction every adopter hits. Legacy browser support for adaptiveStream depends on consumers adding ResizeObserver/IntersectionObserver polyfills themselves, and the v1→v2 migration guide signals the API isn't fully stable long-term.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →