Vai al contenuto
Dialova

Documentazione IRC · Avanzato

Negoziare le capacità con CAP

La negoziazione CAP permette di scegliere le estensioni che un client sa gestire. L’elenco del server è una proposta, non un’attivazione automatica. Una macchina a stati corretta è essenziale quando entrano in gioco SASL o un elenco di capacità suddiviso.

Il team di Dialova · Verificato il

Ottenere l’elenco completo #

CAP LS 302 richiede l’annuncio moderno. Un server può inviare più righe; un parametro * dopo LS indica che ne seguirà un’altra. Raccogli l’intero elenco prima di decidere. Un valore come sasl=PLAIN,EXTERNAL descrive i meccanismi; il nome da richiedere resta sasl.

Scambio IRC: 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

Attivare solo ciò che si sa gestire #

Il client sceglie un elenco e invia CAP REQ. ACK conferma l’attivazione; NAK rifiuta la richiesta. Non considerare attiva una capacità soltanto annunciata. I valori ricevuti in LS non vanno copiati alla cieca in REQ.

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

Durante la registrazione IRC, CAP ne sospende il completamento. Esegui l’autenticazione prevista e poi invia CAP END per proseguire. Un’interfaccia non deve indicare «connesso» solo perché il socket TLS è aperto.

Dopo la registrazione e in caso di modifiche #

CAP LIST mostra le capacità attive. CAP REQ può essere usato anche dopo la registrazione. Le notifiche CAP NEW e CAP DEL fanno parte del meccanismo cap-notify: un servizio non disponibile può cambiare ciò che il server offre. Il client deve aggiornare il proprio stato, senza continuare come se una capacità rimossa funzionasse ancora.

Con un server storico che non comprende CAP, un client può prevedere una connessione classica. Se una regola impone l’autenticazione prima dell’accesso, un ripiego silenzioso su una connessione meno protetta non è accettabile.

Un esempio di conseguenza pratica #

Su Ergo, negoziare la cronologia esplicita può disattivare il reinvio automatico dei messaggi persi. Un client che annuncia questa capacità deve quindi gestire il recupero previsto, non solo riconoscerne il nome. Dialova conserva poi i messaggi privati web nella propria cronologia: le responsabilità del server e dell’applicazione restano distinte.

Fonti e verifica

Gli esempi usano nickname e domini fittizi, tranne gli endpoint esplicitamente documentati. Le estensioni e le impostazioni specifiche di una rete sono indicate nel testo.