Fair points, and appreciate the pushback.

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?