- Shipped
- September 3, 2026 at 8:03 AM UTC
- Author
- Kamo
- Commit
- d8f5092
The fork already carries Meet's whole remote-control feature, and none of it has ever been reachable. The receiver half waits on a PostMessage transport for a host application to answer `supported`; upstream that host is the Electron app, which injects events with robotjs. In a browser tab nothing answers, so enableReceiver never runs, the remote-control disco feature is never advertised, and the menu item is invisible to everyone. A web page cannot inject input into its own operating system, so this adds the piece that can: a small native agent on the machine being controlled. It speaks the existing protocol verbatim, so the browser keeps working the way people already join meetings — no desktop app to install instead. Go, because the two platforms that matter need no cgo: Windows drives SendInput through the stdlib, and Linux writes to /dev/uinput, which being kernel-level works identically under X11 and Wayland where XTest would silently do nothing. macOS uses CoreGraphics and so builds on a Mac. Dependencies are deliberately zero, including a hand-written RFC 6455 server — a binary that can type on your keyboard should not have a supply chain, and its build should never need the network. Four independent gates guard it: loopback-only binding, an Origin allowlist, a one-time approval given on the user's own desktop through a native dialog no web page can summon or answer, and the meeting's own consent for every session. A heartbeat releases every held key and button if the tab dies mid-gesture. The web half comes next; this is inert until then.