On ROS being the standard — you're right that ROS exists,
but adoption outside research/academia is still fragmented.
Boston Dynamics, Universal Robots, and most industrial arms
don't natively speak ROS — teams still write glue code.
RoboAPI is trying to be that glue as a managed layer rather
than a DIY problem.
On REST being wrong for robots — completely agree on the
pub/sub point. REST is the entry point for developer
familiarity but RoboAPI already has WebSocket streaming for
telemetry. The next step is moving commands to pub/sub too.
Interesting that you mention Transitive Robotics — the
blackboard pattern is something I've been thinking about
for the fleet layer.
What would the ideal architecture look like from your
experience? MQTT for commands, WebSocket for telemetry,
REST only for configuration?
I built Entangl, an open-source post-quantum A2A (agent-to-agent) communication protocol for AI agents.
The problem: agents are negotiating contracts, executing transactions, and passing sensitive payloads between themselves. All of that traffic is protected by RSA and ECDH — algorithms that Shor's algorithm breaks on a sufficiently large quantum computer. Nation-state adversaries run harvest-now-decrypt-later attacks today.
What Entangl does:
- CRYSTALS-Kyber1024 (NIST FIPS 203) replaces RSA/ECDH key exchange
- CRYSTALS-Dilithium5 (NIST FIPS 204) replaces ECDSA signatures
- Fresh KEM per message — forward secrecy, no session keys to steal
- Each agent has a DID tethered to a human owner for accountability
- Optional BB84 QKD layer via Cirq — eavesdroppers detectable at ~25% QBER
- Routing server forwards encrypted envelopes but cannot read them
Demo: two agents negotiate a GPU compute deal in 1.4s over a live WebSocket server. Rogue agents blocked at registry level. Tampered ciphertext caught by signature check.
On ROS being the standard — you're right that ROS exists, but adoption outside research/academia is still fragmented. Boston Dynamics, Universal Robots, and most industrial arms don't natively speak ROS — teams still write glue code. RoboAPI is trying to be that glue as a managed layer rather than a DIY problem.
On REST being wrong for robots — completely agree on the pub/sub point. REST is the entry point for developer familiarity but RoboAPI already has WebSocket streaming for telemetry. The next step is moving commands to pub/sub too. Interesting that you mention Transitive Robotics — the blackboard pattern is something I've been thinking about for the fleet layer.
What would the ideal architecture look like from your experience? MQTT for commands, WebSocket for telemetry, REST only for configuration?