3 ms·

In all contexts I've worked in so far, allowing the frontend to do ROS topic publications is a major security issue. So what's the advantage of your cloud serv

In all contexts I've worked in so far, allowing the frontend to do ROS topic publications is a major security issue. So what's the advantage of your cloud service vs something similar like https://github.com/groove-x/mqtt_bridge https://github.com/groove-x/mqtt_bridge where you can easily create a MQTT API for your robots by hand-selecting topics to be exposed?

chfritz 2y ago
> easily create a MQTT API That's a bit like asking: why do we need React when we have HTML and JS? ros-tool is built on Transitive, which uses MQTTSync -- an open-source protocol we've developed for doing data sync on top of MQTT (instead of just message passing). So we are several levels up from MQTT. But yes, if people want to, they can easily write their own Transitive capabilities (see https://transitiverobotics.com/docs/develop/creating_capabilities https://transitiverobotics.com/docs/develop/creating_capabil...) and, in fact, the starter-code provided by our capability init script includes example code for subscribing to ROS. So if anyone wants to write their own, I recommend starting with that. But because ros-tool is built on Transitive, a developer can specify permissions at very fine granularity in the JWT they provide to their users, including not permitting any publishing from the front-end, and/or limiting access to specific topics or services.