Protokół IRC

Repartee implementuje pełną obsługę protokołu IRC obejmującą RFC 2812 oraz szeroki zakres rozszerzeń IRCv3, negocjowanych automatycznie w momencie połączenia.

Podstawowy protokół

Podstawowa warstwa IRC obsługuje wszystkie standardowe operacje protokołu zdefiniowane w RFC 2812:

• Rejestracja połączenia -- NICK, USER, PASS i negocjacja możliwości
• Operacje kanałowe -- JOIN, PART, KICK, INVITE, TOPIC, MODE, listy banów
• Wiadomości -- PRIVMSG, NOTICE do kanałów i użytkowników
• Zapytania serwerowe -- MOTD, LUSERS, VERSION, STATS, INFO, ADMIN, TIME, LINKS
• Zapytania użytkowników -- WHO, WHOIS, WHOWAS, NAMES, LIST
• CTCP -- VERSION, PING, TIME, ACTION oraz niestandardowe zapytania CTCP

Możliwości IRCv3

Repartee negocjuje możliwości IRCv3 podczas połączenia za pomocą CAP LS/REQ/ACK. Następujące możliwości są żądane, gdy serwer je obsługuje:

Ratyfikowany tag klienta +typing podróżuje w TAGMSG dzięki message-tags, więc nie wymaga własnej cap.

Pierwszoklasowa obsługa bouncerów (Soju i Lurker)

Repartee traktuje nowoczesne bouncery IRCv3 — Soju oraz Lurker — jako obywateli pierwszej kategorii:

• Połączenia sterujące i automatyczne wykrywanie sieci -- Ustaw bouncer_control = true (lub /server add ... -bouncer-control), aby wynegocjować soju.im/bouncer-networks, pobrać listę wszystkich sieci nadrzędnych i automatycznie otwierać połączenia potomne dla każdej skonfigurowanej sieci. Zarządzaj sieciami na żywo poleceniem /bouncer (list, refresh, connect, add, change, delete).
• Jawne i klasyczne bindowanie sieci -- Zbinduj połączenie bezpośrednio z ID sieci bouncera przez bouncer_network_id (BOUNCER BIND <id>) lub zachowaj tradycyjne selektory sieci w username/PASS (user/net@client). Autojoin jest wyciszany na zbindowanych połączeniach, dzięki czemu bouncer czysto odtwarza własne dołączone kanały.
• Wykrywanie rozmów i historia po stronie serwera -- Wykrywa aktywne kanały i query przez CHATHISTORY TARGETS, stronicuje historię na żądanie i utrzymuje historię bouncera po stronie serwera (bez duplikowania wiadomości w lokalnej bazie SQLite).
• Synchronizacja znaczników przeczytania -- Negocjuje draft/read-marker oraz soju.im/read (MARKREAD), dzięki czemu stan przeczytania jest synchronizowany między TUI Repartee, interfejsem webowym i innymi klientami bouncera.
• Komendy bouncera -- Przeszukuj historię po stronie serwera przez /bsearch (soju.im/search lub CHATHISTORY BETWEEN/AROUND), zarządzaj metadanymi pin/mute/block przez /bmeta, zarządzaj certyfikatami klienta TLS przez /bcert, uwierzytelniaj konta nadrzędne przez /auth i /account oraz wysyłaj pliki do 64 MiB przez usługę FILEHOST poleceniem /upload.

Historia serwera i multiline

Gdy serwer lub bouncer (soju, lurker, ergo, …) ogłasza draft/chathistory, Repartee pobiera historię przez sieć: przewiń kanał ku górze, aby stronicować starsze wiadomości (CHATHISTORY BEFORE), otwórz pusty bufor query na bouncerze, aby pobrać jego ostatni backlog, a po ponownym połączeniu luka od czasu twojej ostatniej wiadomości zostanie uzupełniona automatycznie (CHATHISTORY AFTER/LATEST). Bezpośrednie połączenia IRC zapisują historię w lokalnej bazie SQLite, natomiast połączenia bouncerowe utrzymują historię w pamięci jako zarządzaną przez serwer. Historia jest deduplikowana po msgid i renderowana dyskretnie (bez zalewu powiadomień).

draft/multiline pozwala, aby wklejona lub złożona wiadomość wieloliniowa przemieszczała się jako pojedyncza logiczna wiadomość — obudowana w jeden BATCH, składana ponownie po drugiej stronie i bezpieczna E2E, tak aby zaszyfrowany blok pozostał jedną jednostką RPE2E. W TUI Alt+Enter wstawia podział linii. Zobacz referencje obsługi IRCv3, aby poznać pełne zachowanie.

Wskaźniki pisania

Repartee implementuje ratyfikowany tag klienta IRCv3 +typing, dzięki czemu widzisz, kto właśnie tworzy wiadomość w bieżącym kanale lub query — pokazywane jako element status line w TUI i odpowiadający mu wskaźnik w interfejsie webowym (alice and bob are typing…).

Powiadomienia są ograniczane tempem do jednego co 3 sekundy i wygasają samoczynnie (6 s po active, 30 s po paused), więc rozmówca, który zniknie w połowie zdania, nigdy nie zostawia zawieszonego wskaźnika. Wysłanie wiadomości wycofuje wskaźnik. Szkic z /me liczy się jako pisanie; szkic /command już nie. Ramki pisania są wliczane do zwykłego flood budget, a TAGMSG nigdy nie otwiera bufora, nie trafia do twojego logu ani nie zwiększa licznika nieprzeczytanych.

Uwierzytelnianie SASL

Repartee obsługuje sześć mechanizmów SASL do uwierzytelniania w serwisach IRC i bouncerach:

• EXTERNAL -- uwierzytelnianie oparte na certyfikacie klienta TLS (client_cert_path z łańcuchem PEM i kluczem)
• ECDSA-NIST256P-CHALLENGE -- uwierzytelnianie kluczem publicznym NIST P-256 metodą wyzwanie-odpowiedź
• SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1 -- solone uwierzytelnianie wyzwanie-odpowiedź z weryfikacją podpisu serwera i bez przesyłania hasła otwartym tekstem
• PLAIN -- uwierzytelnianie nickiem i hasłem
• OAUTHBEARER -- uwierzytelnianie tokenem bearer OAuth 2.0 wg RFC 7628 (jawny wybór przez sasl_mechanism = "OAUTHBEARER" dla bouncerów obsługujących OAuth)

Obsługa WHOX

WHOX (rozszerzony WHO) jest automatycznie wykrywany, gdy serwer ogłasza go przez ISUPPORT. Repartee używa zapytań WHOX do uzupełniania nazw kont i pełnych informacji user@host dla wpisów nicków, dostarczając bogatsze dane użytkowników w liście nicków i umożliwiając funkcje oparte na kontach, takie jak extbany.

Pełna zgodność na serwerach z rodziny ircu oraz w IRCnecie. /who — i metadane listy nicków zasilane przez automatyczne WHO przy wejściu na kanał — rozumie odpowiedzi ze świadomością SID/UID wysyłane przez te ircd, więc stan away, nazwy kont, ident i prawdziwe hostnamy uzupełniają się tam poprawnie, zamiast wracać puste. Repartee dobiera właściwy selektor pól dla danej linii serwerów, rozróżnia układ odpowiedzi po liczbie argumentów i usuwa dodatkowy token SID z IRCnetu, dzięki czemu nie jest już renderowany sklejony z realname. Zwykłe WHO (352) także aktualizuje wpisy nicków, więc nawet serwery bez WHOX dostarczają stan away i prawdziwe hostnamy.

Extban

Repartee obsługuje rozszerzony typ bana $a:account, który banuje użytkowników po nazwie konta serwisów zamiast po masce hosta. Jest to bardziej niezawodne niż bany po masce hosta, ponieważ konta utrzymują się między ponownymi połączeniami i zmianami hosta.

Użyj skrótu /ban -a, aby szybko ustawić ban oparty na koncie na użytkowniku w bieżącym kanale.

DCC CHAT

Repartee obsługuje bezpośrednie połączenia czatu peer-to-peer za pomocą protokołu DCC CHAT:

• Tryby aktywny i pasywny -- inicjowanie bezpośrednich połączeń lub użycie odwróconego (pasywnego) DCC dla użytkowników za NAT
• Konwencja bufora =nick -- czaty DCC pojawiają się jako =Alice na liście buforów, zgodnie z zachowaniem irssi
• Automatyczne wykrywanie IP -- z gniazda IRC, z ręcznym nadpisaniem przez /set dcc.own_ip
• Maski automatycznej akceptacji -- konfiguracja zaufanych masek hostów do automatycznego akceptowania żądań DCC
• Polecenia z uzupełnianiem Tab -- /dcc chat, /dcc close, /dcc list, /dcc reject

Ochrona przed floodem

Repartee zawiera wbudowaną ochronę przed floodem, aby zapobiec rozłączeniu za wysyłanie zbyt wielu wiadomości zbyt szybko. Wiadomości wychodzące są ograniczane tempem, aby przestrzegać progów floodu po stronie serwera (w tym limitów SAFERATE ogłaszanych w ISUPPORT przez bouncery i dostawców), z automatycznym kolejkowaniem i opróżnianiem.

Wykrywanie netsplitów

Zdarzenia netsplit (awarie połączeń serwer-serwer) są automatycznie wykrywane i wyświetlane jako zwinięte, czytelne podsumowania zamiast zalewania kanału pojedynczymi wiadomościami QUIT i JOIN. Wykorzystuje to możliwość IRCv3 batch, gdy jest dostępna, z heurystycznym wykrywaniem opartym na wzorcach jako rozwiązaniem awaryjnym.

Obsługa wielu sieci

Repartee obsługuje jednoczesne połączenie z wieloma sieciami IRC. Dodaj wiele sekcji [servers.*] w pliku konfiguracyjnym, a każda sieć otrzyma własne połączenie, zestaw buforów kanałów i niezależny stan. Wszystkie połączenia współdzielą jedną pętlę zdarzeń dla wydajnego wykorzystania zasobów.