Hotline Server Protocol v1.8.5
Hotline communicates over TCP using a binary frame protocol. All multi-byte integers are big-endian. No padding or alignment bytes appear in the wire format. This reference covers the documented handshake, transaction frame structure, parameter encoding, and the subset of routed transactions explicitly described by the repository reference set.
mxd implements the protocol faithfully, not slavishly. Where the original specification is ambiguous, this reference records the interpretation adopted and the evidence supporting it. Where client behaviour diverges from the specification, the compatibility matrix documents the divergence and the adapter-level shim that handles it.
Session handshake
The client initiates with a 12-byte preamble: the four-byte protocol identifier, the protocol version, and the client sub-version fields used by compatibility policy:
// 12-byte handshake preamble protocol_id: [0x54, 0x52, 0x54, 0x50] // "TRTP" version: 0x0001 // protocol version sub_version: u32 // compatibility marker reserved: u16 // retained by the preamble layout
The server validates the identifier and version, then sends an
8-byte handshake reply with an error code: 0 for success, 1
for invalid protocol, 2 for unsupported version, and 3 for
handshake timeout. Idle sockets are dropped after the five-second
handshake timeout. Only after that reply does the server begin
accepting transaction frames, and the negotiated sub-protocol and
sub-version remain recorded in connection state for the lifetime of
the session.
Interpretation: The protocol identifier is ASCII TRTP (Transaction Request/Transaction Protocol). The original specification does not name the protocol; this identifier appears in packet captures and is universally recognised by clients.
Compatibility negotiation
The handshake is only the first half of compatibility detection. mxd also records login metadata and text-encoding behaviour so the reply path can stay client-specific without lying about broader feature parity.
Login field gating
sub_version == 2 identifies SynHX. Otherwise, login field 160 distinguishes Hotline 1.8.5 (151..=189) from Hotline 1.9 (>=190).
Replies always include the server version field, while Hotline 1.8.5 and 1.9 clients also receive fields 161 and 162. SynHX and unknown or legacy versions omit those banner extras on purpose.
XOR heuristics
XOR compatibility is heuristic and per-connection rather than negotiated by a clean capability bit. The adapter enables it when text-bearing payloads look invalid until XOR-decoded, then keeps that transform aligned on replies.
The currently evidenced scope covers XOR login, XOR news payloads, and the guard that plaintext message payloads do not accidentally enable XOR mode. Broader parity still belongs to the compatibility matrix and roadmap.
Transaction frame structure
Every transaction begins with a 20-byte header. Fields are fixed-width, big-endian, with no padding:
Field definitions
Reserved. Must be zero in all current transactions.
0x00 for client requests, 0x01 for server replies.
Identifies the transaction. 0x006B is Login, 0x012C is Get User Name List, etc.
Client-assigned identifier. Server replies echo this value to correlate request and response.
Zero on success. Non-zero indicates error; see error catalogue.
Total payload size in bytes, excluding the 20-byte header.
Payload size in this fragment. For single-frame transactions, equals total_size.
Parameter encoding
Transaction payloads consist of typed parameters. Each parameter is a TLV (type-length-value) structure:
type_code: u16 // Parameter type identifier length: u16 // Value length in bytes value: [u8; length] // Raw value data
Common parameter types include integers, strings, and binary data. String parameters may be XOR-encoded; mxd detects and decodes these transparently when the connection has entered that compatibility mode.
XOR encoding: Some clients XOR-encode text fields with 0xFF. The wireframe layer detects this by examining early text-bearing transactions, especially Login, and applies the same transform only to text fields for the remainder of that connection.
Transaction catalogue
The reference set supports only a conservative catalogue here. The pages and docs agree on login, authenticated-session continuity, selected file routing, and selected news routing. Other transactions are still design material or roadmap work and should not be read as fully implemented.
Design depth versus shipped scope: the reference set goes much further than this routed subset. It documents file operations 200 through 213 with resumable transfers, aliasing, folder upload and download, comments, and ACLs; chat rooms with invites, subjects, and persisted history; and news bundles, categories, and threaded article pointers. Those designs matter, but they are not all implemented today. The subsystems page documents these designs in full.
Authenticate with username and password
Retrieve list of connected users
Retrieve file metadata by path
Send private message to user
Scope note: This page is intentionally narrower than a full protocol manual. For current support claims, defer to the compatibility matrix and roadmap rather than inferring completeness from this catalogue.