Förhandla funktioner med CAP

Läs hela listan #

CAP LS 302 begär modern annonsering. Servern kan skicka flera rader. Parametern * efter LS betyder fortsättning. Samla hela listan före beslut. sasl=PLAIN,EXTERNAL anger mekanismer, men funktionsnamnet att begära är 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

Aktivera bara det som stöds #

Klienten väljer en lista och skickar CAP REQ. ACK bekräftar och NAK nekar. En annonserad funktion är inte aktiv. Kopiera inte LS-värden blint till REQ.

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

Under registrering pausar CAP slutförandet. Utför avsedd autentisering och skicka sedan CAP END. Gränssnittet ska inte visa ansluten bara för att TLS-socketen är öppen.

Efter registrering och vid förändringar #

CAP LIST visar aktiva funktioner. CAP REQ kan även användas efter registrering. CAP NEW och CAP DEL ingår i cap-notify. Otillgängliga tjänster kan ändra serverns erbjudande. Klienten måste uppdatera tillståndet och inte fortsätta använda borttagna funktioner.

Äldre servrar utan CAP kan hanteras med klassisk anslutning. Om policyn kräver autentisering före åtkomst är tyst degradering inte acceptabel.

Ett konkret exempel #

På Ergo kan förhandling av uttrycklig historik stänga av automatisk leverans av missade meddelanden. En klient som begär funktionen måste därför hantera återupptagandet, inte bara känna igen namnet. Dialova sparar sina privata webbmeddelanden i separat historik. Serverns och appens ansvar är skilda.

• Förstå grupper som transporterar historik →
• Autentisera kontot under anslutningen →