Why we chose gRPC, and not ACP
The question came up while we were wiring the desktop to the agent: why are we hand-rolling a gRPC protocol when the Agent Client Protocol (ACP) already exists for exactly the "UI talks to an agent" problem? It was a…
4 post(s)
The question came up while we were wiring the desktop to the agent: why are we hand-rolling a gRPC protocol when the Agent Client Protocol (ACP) already exists for exactly the "UI talks to an agent" problem? It was a…
Every product screenshot and demo video in FutureOS — including the figures in this blog — is rendered by driving the real React UI in headless Chrome against mock data. No display, no running app, no hand-drawn mockups. The same harness doubles as a UI regression tool.
The product promise is one line: the agent should not touch what you did not allow. Delivering it takes three completely different OS mechanisms — Seatbelt, Bubblewrap, and a restricted token with NTFS ACLs — and an honest list of places where the promise cannot be fully kept.
FutureOS Mobile controls sessions on your desktop over a NATS relay. The relay is on the public network, so it has to be treated as hostile — able to drop, reorder, replay and fabricate messages, but never able to read a command or forge one. Here's how the v2 channel achieves that with a Noise handshake and a ChaCha20-Poly1305 record layer.