The VLC Legend Steps Into the Robot World
Jean-Baptiste Kempf didn’t invent remote control. But he did spend years solving the exact same kind of latency and synchronization headaches that plague modern robotics today — only his problems were pixels, not pistons.
You’ve probably used VLC Media Player at least once. Maybe your computer came preloaded with it, or maybe you downloaded the orange traffic-cone icon on a whim and never looked back. It’s been downloaded over 6 billion times, mostly because Kempf wanted video to just… play. No matter the format, no matter the platform, no matter how bad the connection.
That obsession with real-time delivery is where Kyber begins. Not with robots, but with reliability.
More Than Just a Video Player
Kyber is Kempf’s new startup, quietly raised to $5 million in seed funding led by Lightspeed. The pitch? Build the infrastructure layer physical AI has been missing — an open-source SDK that synchronizes video, sensor data, and control signals across millions of devices with minimal latency.
Don’t mistake this for another cloud robotics play. This isn’t about training a model on sensor data or simulating navigation in the cloud — it’s about getting commands from human operators (or autonomous agents) to hardware physically far away, without hesitation.
“The largest fleets today have maybe 2,000 or 3,000 vehicles,” Kempf told TechCrunch. “Imagine you need to manage millions of them; that’s not the same thing.”
It’s a bridge from desktop video to physical control — and it turns out the challenges are almost identical: you’re streaming a stream of reality, not just a stream of pixels.
Every millisecond matters. If you control things in the real world, every millisecond matters.
Kempf doesn’t mince words here. For a robot, lag doesn’t mean buffering — it means missed steps, dropped payloads, or worse. That’s why Kyber borrows its name from a Star Wars reference: lightsaber crystals, because precision and timing are non-negotiable.
Why Latency Is the New Line in the Sand
Traditional remote-control systems treat latency like a side effect — something you optimize away after the fact. Kyber treats it as the central constraint.
Consider how most industrial fleets operate today: a control center, maybe a local edge server, and then the physical hardware. A command travels across networks, perhaps through proxies or gateways, and arrives milliseconds later. For one or ten devices? Fine. For hundreds? Acceptable. For thousands? You’re lucky if the control loop stays stable.
Kyber was built to push past that ceiling. It starts with Kempf’s experience building video infrastructure at Shadow, the cloud-gaming startup he led as CTO. Streaming high-quality gameplay across continents taught him how to squeeze every last bit of speed from a network stack — and how to design around the limits of real hardware.
The same principles now shape Kyber’s SDK: video compression techniques have been repurposed to reduce sensory payload without sacrificing control fidelity; scheduling mechanisms from distributed gaming setups help batch commands and sensor updates efficiently.
But streaming alone doesn’t solve robotics. You also need to handle compute variance across devices — a small drone might have 1/100th the CPU of an industrial robot. Kyber tunes itself to device capability, throttling high-bandwidth video feeds on constrained endpoints while preserving the control loop. It’s not just low latency; it’s consistent latency across wildly different hardware.
This becomes critical when AI agents start managing fleets on their own. Observability isn’t an afterthought — it’s baked in, so you know when the latency isn’t where it should be, before a system becomes unstable.
Real-Time Control: From Pixels to Pistons
A Dual License, A Forward-Facing Team
Here’s where Kyber departs from pure open-source projects: it’s not just code — it’s a business model wrapped around real-world constraints.
The core is open source. Anyone can pull the repo, deploy a test fleet of ten devices, and contribute improvements back to the community. But for anyone who needs reliability at scale — enterprises, defense contractors, telcos — Kyber sells a commercial variant bundled with forward-deployed engineer (FDE) support.
Think of it this way: you get the same SDK, but Kyber’s team lives inside your deployment pipeline for as long as needed. They help you tune the system for your exact network topology, hardware constraints, and security protocols. Palantir does this — now Kyber is doing it for robotics infrastructure.
This hybrid approach solves two problems:
- Open source builds trust and broad adoption among developers.
- FDE services protect margins and deliver high-touch value where it matters most: reliability under pressure.
Kyber’s team currently stands at 25 full-time staff, with headquarters in Paris and outposts in San Francisco and Singapore — a small team meant to scale fast when demand spikes. And that demand is already showing up in deployment contracts across defense, telco, and robotics verticals.
The FDE Model: Embedded Engineering for Physical AI
The Name’s Not the Same as That Cryptography Standard
One final clarification: Kyber isn’t related to CRYSTALS-Kyber, the NIST-standardized post-quantum cryptographic algorithm.
The cryptographic Kyber is a key encapsulation mechanism (KEM) based on Module-Lattice problems. It’s used by Cloudflare, AWS Key Management Service, and others for quantum-resistant encryption.
The robotics Kyber — Kempf’s project — takes the name because of a thematic nod to lightsabers, not lattice cryptography. Still, developers often assume they’re related, especially when searching for security compliance guidance around Kyber deployments.
To avoid confusion in your own systems:
- If you’re looking for PQC best practices, search CRYSTALS-Kyber or NIST Post-Quantum Cryptography.
- If you’re building robot fleets or remote-device control, you want Kyber by Jean-Baptiste Kempf.
They’re both important. Just not in the same conversation — at least, not yet.
Security & Compliance Analysts, Pay Attention
This is where Kyber starts to matter beyond robotics teams and infrastructure engineers — straight into your security posture review.
Most remote-control software today lives in siloed, proprietary systems. Defense contractors build their own; telcos maintain legacy platforms with decades of tech debt. There’s little shared telemetry, few standardized security controls, and zero industry-wide visibility into how commands are authenticated, encrypted, or audited.
Kyber’s potential to shift that balance is huge. A uniform infrastructure means:
- Easier compliance mapping: one SDK, one set of security controls to audit.
- Faster incident response: common threat models across fleets.
- Shared responsibility models that actually work at scale.
If Kempf pulls this off, the Security & Compliance Analyst won’t just see Kyber as another tool — they’ll see it as a foundational control plane for physical AI operations.
What Comes Next?
The road from 6 billion VLC downloads to millions of synchronized robots isn’t linear. But Jean-Baptiste Kempf has already proven he can build software that works anywhere — the same way, everywhere.
Kyber’s next milestone isn’t just scaling to millions of devices. It’s proving that open infrastructure for physical AI can be both secure and maintainable, without becoming a bottleneck.
The test is already underway — in factories, on streets, and aboard ships, where real humans are already depending on real-time control to get things done. And if it works, we won’t notice the software anymore.
We’ll only see what it enables: robots that don’t hesitate, drones that never miss a command, and the first real infrastructure layer for physical AI.
It’s not the end of robotics. It’s just the beginning — and Jean-Baptiste Kempf is handing us the remote.