Obsługa IRCv3

Kompleksowy status implementacji funkcji protokołu IRC w repartee, obejmujący podstawowy protokół RFC 2812 i rozszerzenia IRCv3.

Negocjacja możliwości

repartee implementuje pełny framework negocjacji możliwości IRCv3, w tym CAP LS 302 z parsowaniem wieloliniowym, CAP REQ/ACK/NAK oraz CAP NEW/DEL dla zmian możliwości w czasie pracy.

Poziom 1 -- wymagane

Poziom 2 -- wysoka wartość

Poziom 3 i rozszerzenia bouncerów

Historia po stronie serwera (draft/chathistory)

Gdy serwer lub bouncer (soju, lurker, ergo, …) ogłasza draft/chathistory, repartee żąda historii przez sieć — dzięki czemu nie musisz już przełączać się do przeglądarki logów tylko do odczytu, aby czytać starsze wiadomości.

• Wykrywanie rozmów (CHATHISTORY TARGETS) -- na połączeniach bouncerowych repartee automatycznie wykrywa aktywne kanały i rozmowy prywatne po połączeniu i pobiera ich ostatni backlog (display.backlog_lines). Otwarcie pustego bufora query na bouncerze również pobiera jego ostatnią historię na żądanie.
• Stronicowanie scroll-back (CHATHISTORY BEFORE) -- przewijanie kanału lub query ku górze stronicuje starsze wiadomości i dodaje je na początek widoku na żywo (w stylu irssi/WeeChat/The Lounge). W interfejsie webowym pozycja przewijania jest zakotwiczona, więc ładowanie starszych stron nigdy nie powoduje przeskoku widoku, a viewport automatycznie wypełnia się przy świeżym połączeniu, dzięki czemu scroll-back jest dostępny nawet zanim okno się przepełni.
• Gap-fill po ponownym połączeniu (CHATHISTORY AFTER / LATEST) -- po ponownym połączeniu wypełnia lukę od ostatniej widzianej wiadomości, więc nic nie ginie podczas krótkiej przerwy. Wielostronicowe luki są stronicowane aż do nadrobienia zaległości.
• Zakresy czasowe i kontekst (CHATHISTORY BETWEEN / AROUND) -- /bsearch between pobiera historię z podanego przedziału czasu na serwerach z draft/chathistory, a /bsearch context <row> dociąga otaczający kontekst dla dowolnego wyniku wyszukiwania przez CHATHISTORY AROUND.
• Model przechowywania -- bezpośrednie połączenia IRC zapisują historię w lokalnym backlogu SQLite, natomiast połączenia bouncerowe utrzymują historię w pamięci jako zarządzaną przez serwer, bez duplikowania wiadomości w lokalnej bazie SQLite.
• Ciche wczytywanie i deduplikacja -- batche historii są renderowane w miejscu bez ponownego wyzwalania powiadomień ani liczników aktywności, a wiersze są deduplikowane po msgid (z awaryjnym znacznikiem czasu w milisekundach dla serwerów bez msgid). draft/event-playback jest żądane obok, dzięki czemu zmiany JOIN/PART/trybu są odtwarzane wewnątrz batcha.

Wiadomości wieloliniowe (draft/multiline)

draft/multiline pozwala, aby prawdziwie wieloliniowa wiadomość przemieszczała się jako pojedyncza logiczna wiadomość zamiast N osobnych linii.

• Wychodzące -- wklejona lub złożona wiadomość wieloliniowa jest obudowana w jeden BATCH typu draft/multiline, z poszanowaniem ogłaszanych przez serwer limitów max-bytes/max-lines, oraz scalana przy wklejaniu, dzięki czemu wklejenie jest jedną wiadomością, a nie zalewem. Jest to bezpieczne dla E2E: zaszyfrowana wiadomość wieloliniowa pozostaje jedną jednostką RPE2E.
• Przychodzące -- przychodzące batche multiline są składane w jedną wiadomość do wyświetlenia i przechowania; zbyt duże lub niespójne batche są odrzucane, a błędy FAIL BATCH MULTILINE_* są ujawniane, a nie pomijane.
• Kompozycja w TUI -- naciśnij Alt+Enter, aby dodać podział linii w kompozytorze i wysłać cały blok jako jedną wiadomość wieloliniową.
• Web -- kompozytor webowy wysyła wieloliniowe wejście jako jedną wiadomość zachowującą \n, gdy cap jest aktywny (i nadal wraca do wysyłania linia po linii, gdy nie jest).

Wskaźniki pisania (+typing)

repartee implementuje ratyfikowany tag klienta +typing. Jest przenoszony przez TAGMSG i wymaga jedynie message-tags, więc nie ma osobnej możliwości do wynegocjowania ani niczego do skonfigurowania, aby zaczął działać.

• Stany -- active (piszesz wiadomość), paused (tekst nadal jest w polu wprowadzania, ale na chwilę przestałeś pisać) oraz done (pole wprowadzania znów jest puste). active i paused renderują się identycznie; rozróżnienie nie jest ujawniane.
• Czasy -- powiadomienia są ograniczane do jednego na 3 s na cel. Odebrany active wygasa po 6 s, a paused po 30 s, więc rozmówca, którego program padnie w połowie zdania, nigdy nie zostawi zablokowanego wskaźnika. Wysłanie prawdziwej wiadomości niejawnie wycofuje wskaźnik -- po niej nie jest już wysyłany done.
• Co liczy się jako pisanie -- niepusty tekst, który nie jest poleceniem (/command). Szkic /me (lub /action ) jest wiadomością, więc ogłasza pisanie.
• Wysyłanie i odbieranie są rozdzielone -- [typing] show steruje tym, czy widzisz innych; send_channels i send_queries niezależnie sterują tym, czy ogłaszasz własne pisanie -- odpowiednio na kanałach i w prywatnych query. Wszystkie trzy są domyślnie włączone.
• Zgodność -- repartee wysyła zawsze wyłącznie ratyfikowany +typing, ale przy odbiorze nadal akceptuje przedratyfikacyjny +draft/typing. Tag jest tłumiony na serwerach, które blokują go przez ISUPPORT CLIENTTAGDENY, i nigdy nie jest wysyłany na niezarejestrowanym połączeniu.
• Nigdy nie hałasuje -- TAGMSG nigdy nie otwiera bufora, nigdy nie trafia do logu ani scroll-backu i nigdy nie zwiększa licznika aktywności ani nieprzeczytanych. Odtwarzane batche historii oraz odbicia własnych wiadomości z echo-message są ignorowane, a reguły listy ignorowanych obowiązują. Stan pisania jest porzucany przy PART, QUIT, KICK, zmianie nicka, netsplicie i rozłączeniu.
• Bezpieczne dla flood-protection -- ramki pisania są wliczane do tego samego budżetu antyfloodowego co wszystko inne i są pomijane, gdy zapas się kończy, więc wskaźnik nigdy nie doprowadzi do wyrzucenia cię za flood.
• Skrypty -- podepnij api.on("irc.typing", ...), aby obserwować lub tłumić powiadomienia o pisaniu. Zobacz dokumentację Lua API.

Wskaźnik jest renderowany przez element status line typing (obecny na domyślnej liście [statusbar] items) zarówno w TUI, jak i w interfejsie webowym: alice is typing…, alice and bob are typing…, alice, bob and 2 others are typing….

RFC 2812 -- protokół podstawowy

Rejestracja połączenia

Operacje na kanałach

Wiadomości i zapytania

CTCP

ISUPPORT (005)

Rozszerzenia niestandardowe

WHOX na ircd z rodziny ircu i na IRCnet

/who -- oraz metadane listy nicków, które zasila automatyczne WHO przy dołączeniu -- rozumieją świadome SID/UID odpowiedzi wysyłane przez te ircd, dzięki czemu stan away, nazwy kont, ident i prawdziwe hostname wypełniają się poprawnie zamiast wracać puste.

• Selektor pól zależny od linii ircd -- przenośny selektor %tcuihnfar jest używany wszędzie; IRCnet ircd 2.12 (wykrywany po tokenie ISUPPORT IDCHAN) otrzymuje %tcuihnfaUr, dodający pole U (UID użytkownika). Dodatkowe pole nigdy nie jest wysyłane do innych ircd, gdzie po cichu przesunęłoby układ odpowiedzi.
• Układ odpowiedzi rozróżniany po liczbie argumentów -- 10-argumentowy 354 to układ przenośny, 11-argumentowy to układ IRCnet (z UID). Konto o wartości "0" oznacza, że użytkownik nie jest zalogowany.
• Zwykłe WHO (352) też aktualizuje teraz stan -- wcześniej jedynie wypisywało linię, więc na serwerach bez WHOX zapytanie WHO przy dołączeniu było zmarnowane, a away/host/ident nigdy nie trafiały na listę nicków.
• Poprawka parametru końcowego -- IRCnet wysyła :<hop> <sid> <realname>, podczas gdy RFC mówi :<hop> <realname>, przez co zbłąkany 4-znakowy SID renderował się sklejony z realname. Hopcount jest teraz usuwany wszędzie, a SID tylko na serwerach z linii IRCnet -- oba defensywnie.

Pominięte