Skip to content
df12 Productions Marrakesh Express Daemon
Docs · Compatibility

Client compatibility matrix

This page mirrors `docs/internal-compatibility-matrix.md`, the repository source of truth for support claims. It records only the profiles and scopes backed by that matrix and avoids naming clients or tiers the repository does not document.

Route map
Client compatibility matrix
Compatibility matrixStatus definitionsVerification strategyRelease note compliance
Client Profile Detection Status Supported scope Known deviations Required toggles
Hotline 1.8.5 sub_version != 2; login field 160 in 151..=189 Partial Login handshake and login reply augmentation; text payloads may be auto-decoded if XOR-encoded User-list and messaging parity remain pending later roadmap items None required for default login flow
Hotline 1.9 sub_version != 2; login field 160 in >=190 Partial Login handshake and login reply augmentation; text payloads may be auto-decoded if XOR-encoded User-list and messaging parity remain pending later roadmap items None required for default login flow
SynHX (non-XOR) sub_version == 2; login field 160 accepted Partial Login flow with SynHX banner-field omission semantics Field-level parity outside implemented transactions remains roadmap work None for non-XOR payloads
SynHX (XOR text mode) Same as SynHX plus XOR heuristic triggers on text fields Partial XOR login, XOR message payload detection, XOR news post payload decoding/encoding XOR mode is heuristic until a reliable handshake signal exists Client-side encode toggle when using XOR payloads
Unknown / legacy login version sub_version != 2; login field 160 below 151 or absent Supported Safety behaviour: login reply omits Hotline banner extras and remains protocol-valid Client is treated conservatively as unknown until explicit mapping exists None

Evidence trail: the public matrix stays narrow on purpose. Each profile maps to specific repository helpers and named scenarios rather than to a vague promise of client parity.

  • Hotline 1.8.5 and 1.9: tests/features/wireframe_login_compat.feature scenarios for banner-field inclusion, backed by the compatibility policy helpers named in docs/internal-compatibility-matrix.md.
  • SynHX (non-XOR): tests/features/wireframe_login_compat.feature scenario for banner-field omission.
  • SynHX (XOR): tests/features/wireframe_xor_compat.feature scenarios for XOR login success, XOR message toggling, and the plaintext guard.
  • Unknown or legacy versions: login-compat scenarios that assert banner extras stay omitted while the reply remains protocol-valid.

Status definitions

Supported

Implemented and covered by automated tests for the scope described in the matrix. This label is intentionally narrow.

Partial

Implemented only for listed transactions or behaviours. Other parity work is still pending roadmap delivery.

Planned

Not implemented yet. It appears in the matrix only to prevent over-claiming support.

Verification strategy

Verification follows the evidence listed in the internal matrix. Today that evidence is concentrated on login compatibility, banner-field augmentation or omission, and XOR-mode behaviour rather than on broad end-to-end feature parity.

Test coverage requirements

Current behavioural guarantees captured by tests include:

  • Hotline 1.8.5 and 1.9 login replies include fields 161/162
  • SynHX replies omit fields 161/162
  • Unknown client versions omit banner fields and stay protocol-valid
  • XOR-encoded login and news payloads are accepted when heuristics detect XOR
  • Plaintext message payloads do not accidentally enable XOR compatibility

Open gaps: Session-presence and messaging parity remain future work for the named Hotline and SynHX profiles, and XOR invariants are tracked separately by roadmap and proof work.

Release note compliance

Release notes must reference this matrix. The QA sign-off checklist requires a line that explicitly names docs/internal-compatibility-matrix.md, and it asks reviewers to reject notes that claim support beyond the matrix status.

QA sign-off example 
QA sign-off: compatibility matrix reviewed at docs/internal-compatibility-matrix.md
Deviation recorded in docs/internal-compatibility-matrix.md

Reviewer prompts

  • Link release notes to docs/internal-compatibility-matrix.md and confirm the affected rows were reviewed.
  • Confirm the evidence named in the matrix still matches current behaviour before claiming support.
  • Record any newly discovered deviation in both release notes and the matrix, not in one place only.
  • Ask whether supported clients and required toggles are unchanged, whether changed behaviour is still Partial or Planned, and whether the notes avoid over-claiming.