Link Search Menu Expand Document

ARENA PubSub Message Bus

The ARENA message bus is currently supported by a MQTT Mosquitto broker, modified to keep track of connected clients and data flows. This information is organized into a graph that is available to users and, more importantly, to the runtime supervisor - ARTS. The broker is also configured with a JWT plugin that implements the PubSub ACL on the topic structure (more details below), and we use Mosquitto’s bridging to create clusters of brokers.

PubSub Access Control

The root of trust for an ARENA Realm derives from the Access Control List (ACL) permissions managed by the Authentication and Access Control service. Users are authenticated using OAuth and the service emits JSON Web Tokens (JWT) based on permissions for which scenes users control or grant control as an ACL. PubSub brokers and other services (e.g. the persistence datastore) use JWT to enforce access control. PubSub brokers accept and validate these tokens and use them to allow/disallow publish or subscribe access. We use the PubSub topic structure to sculpt and whitelist which 3D objects, chat, runtime, and other communications bind this ACL to the user’s JWT. To prevent clients from elevating their privileges by publishing malicious messages on the topics they are allowed to publish, we perform client-side checks on message reception and discard invalid messages. See more security details.

A few example topics are included below for context, as well as a list of topic elements used, and which topics are added to the ARENA JWT based upon user and system defined access control list (ACL) settings.

Example Topics

General 3D Object
User 3D Object
Chat Message
AprilTag Detection
VIO Update
Runtime Stdout

Topic Elements

Storage area for AprilTag detection data
Storage area for user text chat messages
Storage area for general use
Storage area for public or open user payload topics
Storage area for scene graphic objects
Storage area for private user to user payload topics
Storage area for runtime process and module data
Storage area for VIO camera pose updates
Storage area for network performance metrics
Namespace for a particular user within the scene
A-Frame object name; object topic should receive mostly A-Frame content
Future use; a namespace we expect to be useful for peer MQTT brokers; probably geographic-based
Namespace for a particular application within the scene
A server-generated ID to establish a unique user connection
Name of particular scene, could be captured from the ATLAS
Appended to control origin of the chat messages: b64encode('{session-id}_{username}')
The ARENA account username for the user

*Names in {} are dynamic

Scene Allowed


  • All scenes: Staff/Admin have rights to all scene objects.
  • Subscribe: Staff
  • Publish: Staff


  • Scene namespaces: scene owners have rights to their scene objects only.
  • Subscribe: specific user: username
  • Publish: specific user: username


  • Individual scenes: did the user set specific public read or public write?
  • Subscribe: public_read=True, or namespace user added editor
  • Publish: public_write=True, or namespace user added editor




  • User-presence objects: scene owners have rights to their scene objects only.
  • Subscribe: public_read=True
  • Publish: specific Anonymous/User, issued ID and username from authentication service.

Sensor Allowed


  • All AprilTag sensors
  • Subscribe: Staff, User, Anonymous
  • Publish: Staff, User, Anonymous


  • VIO or test cameras for student experiments
  • Publish: Staff

Chat Allowed

A user handle is appended to control the origin of the chat messages in the topic and payload to prevent spoofing. Where userhandle = b64encode({session-id}\_{username}).


  • Receive private messages: Read
  • Subscribe: Staff, User, Anonymous


  • Receive open messages to everyone and/or scene: Read
  • Subscribe: Staff, User, Anonymous


  • Send open messages (chat keep-alive, messages to all/scene: Write
  • Publish: Staff, User, Anonymous


  • Private messages to User: Write
  • Publish: Staff, User, Anonymous

Runtime Manager Allowed


  • Open topic for controlling runtime processes
  • Subscribe: Staff, User, Anonymous
  • Publish: Staff, User, Anonymous

Network Metrics Allowed


  • Monitor topic for logging or visualizing metrics
  • Subscribe: Staff, User, Anonymous


  • Topic for writing network metrics
  • Publish: Staff, User, Anonymous