The server advertises labeled-response and standard-replies. Labeled
responses are active only while both labeled-response and its required
batch dependency are negotiated; clients may request those capabilities in
either order. standard-replies is independent.
A client may attach a non-empty label tag of at most 64 UTF-8 bytes to a
command. The value is opaque: the server unescapes it while parsing and escapes
it again on output without interpreting its contents. An absent, empty, or
oversized label does not change ordinary command processing.
The response shape follows the IRCv3 contract:
| Command result | Wire response |
|---|---|
| No ordinary response | One labeled ACK from the server. |
| One response line | The line carries the label tag. |
| Several response lines | A labeled-response BATCH carries the lines, and only its opening line carries label. |
One already-applicable BATCH, such as chathistory |
Its existing opening line carries label; it is not wrapped in a second batch. |
Only output caused by the labeled command on its originating connection is captured. Shared channel updates still reach other members without the label, and unrelated inbound traffic cannot be swept into the response merely because it arrived while the command was running. Response lines pass through the same bounded per-connection queue as all other output.
The IRCv3 self-message exception is preserved. Sending a direct message to the
connection's own nickname produces an unlabeled delivered copy. When
echo-message is negotiated, its separate sender echo is the labeled response;
both copies carry the same message ID. This lets a client distinguish receipt
from acknowledgment without inventing a special local message format.
The standard-replies capability tells the server that arbitrary well-formed
FAIL, WARN, and NOTE messages are understood. Existing extension failures
for chat history, read markers, delivery markers, and account-required
registration use named FAIL replies. A rejected client-supplied source uses
the arbitrary INVALID_SOURCE failure only after this capability is
negotiated, retaining numeric 400 for older clients. Opaque direct-message
rejection similarly uses FAIL PRIVMSG DM_UNAVAILABLE for capable clients and
generic numeric 401 text for older ones; an unavailable NOTICE remains silent.
Standard IRC errors retain
their established numerics, such as 401 and 461; negotiating this capability
does not silently replace familiar numerics with cosmetically different
failures.
The shared JavaScript client negotiates both capabilities. Its command
formatter accepts bounded client tags, and
session.sendLabeledCommand(command, parameters, label) returns the selected
label and exact wire line. If the label is omitted, the session allocates a
connection-local one. Parsed line events expose response and batch tags so an
application can correlate either single responses or all members of a labeled
batch.
The implementation follows the IRCv3 specifications for labeled responses and standard replies.