Skip to content
Dialova

IRC Documentation · Advanced

Negotiate capabilities with CAP.

CAP negotiation allows choosing extensions a client can handle. The server list is a proposal, not automatic activation. A correct state machine remains essential when SASL or a split capability list intervenes.

Dialova Team · Verified on

Discover the complete list. #

CAP LS 302 requests the modern announcement. A server may send multiple lines; a * parameter after LS indicates another line will follow. Accumulate the list before deciding. A value like sasl=PLAIN,EXTERNAL describes mechanisms; the name to request remains sasl.

IRC Exchange: C = client, S = server
C: CAP LS 302
C: NICK Alice
C: USER alice 0 * :Alice
S: :irc.example CAP * LS * :message-tags server-time
S: :irc.example CAP * LS :batch sasl=PLAIN,EXTERNAL

Enable only what is understood #

The client chooses a list and sends CAP REQ. ACK confirms activation; NAK rejects the request. Do not treat a simply announced capability as active. Values received in LS are not blindly copied into REQ.

IRC Exchange: C = client, S = server
C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

During registration, CAP suspends finalization. Perform the intended authentication, then send CAP END to allow continuation. An interface should not announce "connected" only because the TLS socket is open.

After registration and in case of change #

CAP LIST allows viewing active capabilities. CAP REQ can also be used after registration. CAP NEW and CAP DEL notifications relate to the cap-notify mechanism: an unavailable service can modify what the server offers. The client must review its state, not continue as if a removed capability still functions.

On an older server not understanding CAP, a client can provide a classic connection path. If a policy requires authentication before access, a silently degraded connection is not an acceptable solution.

A real-world consequence example #

On Ergo, negotiating explicit history can disable automatic re-sending of missed messages. A client announcing this capability must therefore support the expected recovery, and not just recognize its name. Dialova then retains its Web PVs in its own history: server and application responsibilities remain distinct.

Sources & Verification

Examples use pseudonyms and fictional domains, except for explicitly documented connection points. Network-specific extensions and settings are noted in the text.