Saltar al contenido
Dialova

Documentación IRC · Avanzado

Negociar capacidades con CAP

La negociación CAP permite elegir las extensiones que un cliente sabe procesar. La lista del servidor es una propuesta, no una activación automática. Una máquina de estados correcta es esencial cuando intervienen SASL o una lista de capacidades dividida en varias líneas.

El equipo de Dialova · Verificado el

Obtener la lista completa #

CAP LS 302 solicita el anuncio moderno. El servidor puede enviar varias líneas; un parámetro * después de LS indica que seguirá otra. Reúne la lista completa antes de decidir. Un valor como sasl=PLAIN,EXTERNAL describe mecanismos; el nombre que debes solicitar sigue siendo sasl.

Intercambio IRC: C = cliente, S = servidor
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

Activar solo lo que se entiende #

El cliente elige una lista y envía CAP REQ. ACK confirma la activación; NAK rechaza la solicitud. No trates una capacidad anunciada como si ya estuviera activa. No copies sin más los valores de LS a REQ.

Intercambio IRC: C = cliente, S = servidor
C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

Durante el registro IRC, CAP suspende su finalización. Completa la autenticación prevista y envía después CAP END para continuar. La interfaz no debe indicar «conectado» solo porque la conexión TLS esté abierta.

Después del registro y cuando hay cambios #

CAP LIST muestra las capacidades activas. CAP REQ también puede usarse después del registro. Los avisos CAP NEW y CAP DEL pertenecen al mecanismo cap-notify: un servicio no disponible puede modificar lo que ofrece el servidor. El cliente debe actualizar su estado, no seguir como si una capacidad retirada funcionara.

Ante un servidor antiguo que no entiende CAP, el cliente puede prever una conexión clásica. Si una política exige autenticarse antes de acceder, degradar silenciosamente la conexión no es una solución aceptable.

Un ejemplo de consecuencia práctica #

En Ergo, negociar el historial explícito puede desactivar el envío automático de mensajes perdidos. Por eso, un cliente que anuncia esta capacidad debe encargarse de la recuperación esperada, no limitarse a reconocer su nombre. Dialova guarda después sus mensajes privados web en su propio historial: las responsabilidades del servidor y de la aplicación siguen siendo distintas.

Fuentes y verificación

Los ejemplos usan apodos y dominios ficticios, salvo los puntos de conexión expresamente documentados. Las extensiones y los ajustes específicos de una red se indican en el texto.