Knowledge check

Check your knowledge

Choose an answer to see why it is right or wrong.

JavaScript is off, so every explanation is shown at once.

1. 01Why does Massar's agent only ever dial out to the Diyar broker, rather than listening for inbound connections?

   • Dial-out needs no inbound port and no VPN - it fits how most firewalls already default (deny-inbound, allow-outbound) and works regardless of the device's network position.Correct. This is the same posture as AWS SSM and Azure Arc: the device calls the cloud, never the other way around, so nothing has to be opened inbound on the device's network.
   • Because listening sockets are not supported on the platforms Massar targets.Incorrect. Windows and Linux both support listening sockets fine; dial-out is a deliberate security choice, not a technical limitation of the platform.
   • Because an outbound connection is always faster than an inbound one.Incorrect. Speed is not the reason given for the design - the reason is that it removes the need for an inbound port or a VPN on the device.

2. 02What role does the Diyar console broker play once a session is open?

   • It relays WebSocket frames between the agent and the operator's browser terminal - it does not interpret terminal control logic itself, which is owned entirely by the agent.Correct. The agent's own source describes the broker as "a dumb frame pipe; the agent interprets control and owns the PTY."
   • It runs the PTY and the shell on behalf of the device.Incorrect. The PTY and shell run on the device, inside the agent's process - the broker never touches terminal state.
   • It stores the device's per-device token so the agent does not have to send it.Incorrect. The agent presents its own token as an Authorization: Bearer header on every connection; the broker does not hold it on the agent's behalf.

3. 03On the wire between the agent and the operator's browser, what distinguishes a WS Text frame from a WS Binary frame?

   • Text frames carry control messages as JSON (open/resize/close/exit); Binary frames carry raw terminal bytes (PTY stdin/stdout).Correct. This split is symmetric on both hops through the broker: it is how the agent tells a control instruction apart from the shell's actual output.
   • Text frames carry the shell's output; Binary frames carry the operator's keystrokes.Incorrect. Both directions of terminal data - keystrokes in, shell output out - travel as Binary frames. Text frames are reserved for control messages, not terminal content.
   • Text and Binary frames carry the same content; the distinction is only cosmetic.Incorrect. The agent parses Text frames as control JSON and would not attempt to parse terminal bytes as JSON - the two frame types carry structurally different payloads.

4. 04What authorizes an operator to open a session on a given device, and what does the device itself present to authenticate?

   • The operator is gated by Diyar RBAC (operator rank on the device's workspace) and the session is recorded there; the device presents its own per-device secret as an Authorization: Bearer header.Correct. These are two separate boundaries: Diyar RBAC and audit authorize and record the operator; the per-device token authenticates the device to the broker.
   • The device and the operator share the same per-device token, so either side can authenticate as the other.Incorrect. The token belongs to the device alone. Operator authorization is a completely separate mechanism, enforced by Diyar's RBAC.
   • Massar's agent maintains its own list of authorized operators and checks it before opening a PTY.Incorrect. Massar holds no user directory and makes no authorization decision of its own - that decision is made entirely on the Diyar side.

5. 05Which statement about Massar's enrollment and platform support is accurate today?

   • The shipped enrollment path is a pre-issued static per-device token passed to the installer; a graphical device-code/QR enrollment wizard exists in the frontend, but its backend commands are not implemented.Correct. The wizard is a preview of where enrollment is headed, not a working alternative to the token flag today.
   • Massar supports Windows, Linux, and macOS installers today.Incorrect. Only Windows and Linux have a working install path. macOS is deferred - there is no installer or service definition for it, even though a macOS binary is cross-built in CI.
   • The device-code/QR enrollment flow is the primary, fully working way to enroll a device today.Incorrect. That flow is UI and mocks only; the Tauri backend commands behind it are unimplemented. The static per-device token is the real, shipped path.