# MeshCentral 1.2.5 protocol comparison

**Date:** 2026-08-26
**Reference:** deployed-version-pinned `meshctrl.js` source at commit
`b09b1d60328de8e2d2f7387561ed51c64011c82a`.

## Findings

| Area | Official MeshCtrl 1.2.5 | Bridge before this change | Decision |
|---|---|---|---|
| Password authentication | `base64(username),base64(password)` comma-separated header; optional third comma-separated base64 token | Base64 of `username:password[:totp]` | Correct bridge to official wire format |
| Request correlation | `responseid: "meshctrl"` | Numeric `id` | Use unique `responseid` values and match echoed `responseid` |
| Server-version response | `action: "serverversion"`, `responseid`, `result`, `tags` | Expected optional `ver` and numeric `id` | Accept protocol envelope and preserve response fields |
| First application message | No special handshake message; request is sent after `open` | Request sent after `open` | No extra handshake required |
| TLS | Official client disables certificate verification | Bridge requires verification | Keep bridge's safer behavior; do not copy upstream TLS weakness |

## Scope

This comparison covers only the read-only control-channel operations used by the
MVP. Remote commands, diagnostics, events, power operations, file transfer, and
administrative actions remain out of scope.

## Compatibility consequence

The previous implementation could complete the WebSocket upgrade but was not
wire-compatible with MeshCentral's request/response correlation format. The
authentication-header and response-correlation corrections are now covered by
the local protocol tests before any further live read-only attempt.