Saltar para o conteúdo
Dialova

Documentação IRC · Avançado

Negociar capacidades com CAP

A negociação CAP permite escolher as extensões que um cliente sabe processar. A lista do servidor é uma proposta, não uma ativação automática. Uma máquina de estados correta é essencial quando intervêm SASL ou uma lista de capacidades dividida em várias linhas.

A equipa do Dialova · Verificado em

Obter a lista completa #

CAP LS 302 pede o anúncio moderno. O servidor pode enviar várias linhas; um parâmetro * depois de LS indica que virá outra. Reúne a lista completa antes de decidir. Um valor como sasl=PLAIN,EXTERNAL descreve mecanismos; o nome a pedir continua a ser sasl.

Troca 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

Ativar apenas o que se compreende #

O cliente escolhe uma lista e envia CAP REQ. ACK confirma a ativação; NAK recusa o pedido. Não trates uma capacidade apenas anunciada como se estivesse ativa. Não copies cegamente os valores de LS para REQ.

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

Durante o registo IRC, CAP suspende a sua conclusão. Efetua a autenticação prevista e envia depois CAP END para continuar. A interface não deve indicar «ligado» só porque a ligação TLS está aberta.

Depois do registo e quando há alterações #

CAP LIST mostra as capacidades ativas. CAP REQ também pode ser usado depois do registo. Os avisos CAP NEW e CAP DEL pertencem ao mecanismo cap-notify: um serviço indisponível pode alterar o que o servidor oferece. O cliente deve atualizar o seu estado, não continuar como se uma capacidade retirada ainda funcionasse.

Perante um servidor antigo que não compreende CAP, o cliente pode prever uma ligação clássica. Se uma política exigir autenticação antes do acesso, degradar silenciosamente a ligação não é uma solução aceitável.

Um exemplo de consequência prática #

No Ergo, negociar o histórico explícito pode desativar o envio automático das mensagens perdidas. Por isso, um cliente que anuncia esta capacidade deve tratar da recuperação esperada, não apenas reconhecer o nome. O Dialova guarda depois as mensagens privadas web no seu próprio histórico: as responsabilidades do servidor e da aplicação continuam distintas.

Fontes e verificação

Os exemplos usam alcunhas e domínios fictícios, salvo os pontos de ligação expressamente documentados. As extensões e definições específicas de uma rede são assinaladas no texto.