Forhandle capabilities med CAP

Hent hele listen #

CAP LS 302 ber om moderne annonsering. Serveren kan sende flere linjer. En *-parameter etter LS betyr at en ny linje følger. Samle hele listen før du velger. En verdi som sasl=PLAIN,EXTERNAL beskriver mekanismer; navnet du ber om, er fortsatt sasl.

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

Aktiver bare det klienten forstår #

Klienten velger en liste og sender CAP REQ. ACK bekrefter aktivering; NAK avviser forespørselen. Ikke behandle en annonsert capability som aktiv. Verdier fra LS skal ikke kopieres ukritisk inn i REQ.

C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

Under registreringen setter CAP fullføringen på vent. Gjennomfør den planlagte autentiseringen, og send deretter CAP END slik at registreringen kan fortsette. Grensesnittet må ikke melde «tilkoblet» bare fordi TLS-forbindelsen er åpen.

Etter registrering og ved endringer #

CAP LIST viser aktive capabilities. CAP REQ kan også brukes etter registrering. CAP NEW og CAP DEL er del av cap-notify: en tjeneste som blir utilgjengelig, kan endre serverens tilbud. Klienten må oppdatere tilstanden, ikke fortsette som om en fjernet capability fremdeles virker.

For en eldre server uten CAP kan klienten ha en klassisk tilkoblingsmåte. Hvis reglene krever autentisering før tilgang, er en stille nedgradering som omgår kravet, ikke akseptabel.

Et konkret eksempel på en følge #

På Ergo kan forhandling av eksplisitt historikk slå av automatisk levering av tapte meldinger. En klient som annonserer denne capability-en, må derfor implementere forventet gjenopptak, ikke bare kjenne igjen navnet. Dialova lagrer deretter private nettmeldinger i sin egen historikk; serverens og applikasjonens ansvar er fortsatt atskilt.

• Forstå batchene som frakter historikk →
• Autentiser kontoen under tilkoblingen →