Logowanie i wyszukiwanie
repartee zawiera wbudowany system logowania oparty na SQLite z opcjonalnym szyfrowaniem i wyszukiwaniem pełnotekstowym.
Konfiguracja
[logging]
enabled = true
encrypt = false
retention_days = 0 # 0 = keep forever
event_retention_hours = 72 # auto-prune events after 72h (0 = keep forever)
exclude_types = [] # e.g. ["join", "part", "quit"]
Przechowywanie
Logi są przechowywane w ~/.repartee/logs/messages.db przy użyciu SQLite w trybie WAL (Write-Ahead Logging) zapewniającym wydajność przy jednoczesnym odczycie i zapisie.
Schemat bazy danych
Każda wiadomość jest przechowywana z następującymi polami:
| Kolumna | Typ | Opis |
|---|---|---|
msg_id | TEXT | Unikalny UUID |
network | TEXT | Identyfikator połączenia/sieci |
buffer | TEXT | Nazwa kanału lub query |
timestamp | INTEGER | Znacznik czasu Unix |
msg_type | TEXT | Typ wiadomości (privmsg, join itp.) |
nick | TEXT | Nick nadawcy |
text | TEXT | Treść wiadomości |
highlight | INTEGER | 1 jeśli wiadomość jest podświetlona |
ref_id | TEXT | Referencja do głównego wiersza (dla deduplikacji fan-out) |
Deduplikacja fan-out
Zdarzenia takie jak QUIT i NICK dotyczą wielu kanałów. repartee przechowuje pojedynczy pełny wiersz dla pierwszego kanału oraz wiersze referencyjne (z pustym tekstem i ref_id wskazującym na główny wiersz) dla kolejnych kanałów. Oszczędza to miejsce, zachowując jednocześnie historię dla każdego kanału.
Szyfrowanie
Gdy encrypt = true, tekst wiadomości jest szyfrowany algorytmem AES-256-GCM przed zapisem. Klucz szyfrowania jest wyprowadzany z hasła przechowywanego w ~/.repartee/.env:
# ~/.repartee/.env
REPARTEE_LOG_KEY=your-secret-passphrase
Zaszyfrowane logi mogą być przeszukiwane/odczytywane tylko z prawidłowym kluczem.
Wyszukiwanie pełnotekstowe
repartee używa SQLite FTS5 do szybkiego wyszukiwania pełnotekstowego we wszystkich lokalnych logach:
/log search <query>
Wyszukiwanie obsługuje standardową składnię FTS5, w tym dopasowanie fraz ("exact phrase"), dopasowanie prefiksów (prefix*) oraz operatory logiczne (AND, OR, NOT).
Na połączeniach z bouncerami (takimi jak Soju czy Lurker) wiadomości pozostają po stronie serwera i nie są duplikowane w lokalnej bazie SQLite (czaty DCC są nadal logowane lokalnie). Użyj /bsearch, aby przeszukiwać historię po stronie serwera do dedykowanego bufora *search* tylko do odczytu:
/bsearch #channel -from alice -- rust
/bsearch between #channel 2026-03-01T00:00:00Z 2026-03-02T00:00:00Z 100
/bsearch context 1
Polecenia
/log status
Wyświetl status logowania, rozmiar bazy danych i liczbę wiadomości.
/log search <query>
Przeszukaj wszystkie lokalnie zalogowane wiadomości.
/bsearch
Przeszukaj historię przechowywaną po stronie serwera (soju.im/search lub CHATHISTORY BETWEEN / AROUND) na bouncerach i serwerach IRCv3.
Przeglądarka logów tylko do odczytu
Uruchom repartee w trybie przeglądarki logów, aby przejrzeć zapisaną historię bez łączenia się z IRC, ładowania skryptów czy uruchamiania frontendu webowego:
repartee l
repartee logs
W tym trybie baza danych logów otwierana jest tylko do odczytu, a połączenia IRC, serwis webowy, skrypty i autoconnect są wyłączone. Wyświetlany jest standardowy TUI, ale lista buforów budowana jest z katalogu sieci i kanałów znalezionych w logach, pasek tematu pokazuje metadane logu dla każdego bufora, a linia statusu informuje, że jesteś w trybie logu.
Doczytywanie historii
Bufory ładowane są leniwie — otwarcie bufora pobiera najświeższą stronę, a przewijanie w górę automatycznie wczytuje starsze wiadomości z dysku. Pomiędzy sekcjami wstawiane są separatory dni i nagłówki sieci, dzięki czemu długa historia pozostaje czytelna.
Slash-komendy w trybie logu
W trybie przeglądarki logów aktywny jest tylko niewielki dispatcher:
| Polecenie | Opis |
|---|---|
/search <query> | Wyszukiwanie pełnotekstowe w bazie tylko do odczytu (tylko logi w formie jawnej — zaszyfrowane teksty nie są indeksowane) |
/quit | Wyjście z przeglądarki |
/help | Wyświetla dostępne polecenia trybu logu |
W każdej chwili możesz też nacisnąć Q, co działa identycznie jak /quit.
Logi zaszyfrowane
Gdy encrypt = true, tekst logu zapisywany jest jako szyfrogram i /search nie może go indeksować, więc wyszukiwanie w trybie przeglądarki logów nie jest dostępne dla zaszyfrowanych baz. Czytanie buforów nadal działa — wiadomości są deszyfrowane w locie kluczem zapisanym w ~/.repartee/.env.
Historia czatu (backlog)
Po otwarciu kanału, query lub bufora DCC chat, repartee automatycznie ładuje najnowsze wiadomości z bazy danych logów -- dzięki czemu od razu widzisz ostatni kontekst bez konieczności przewijania.
/set display.backlog_lines 20 # default — load last 20 messages
/set display.backlog_lines 50 # load more history
/set display.backlog_lines 0 # disable backlog
Wiadomości backlogu pojawiają się na górze bufora, a po nich wyświetlany jest separator:
─── End of backlog (20 lines) ───
Linie separatora dat są automatycznie wstawiane między wiadomościami z różnych dni, co ułatwia czytanie historii. Znaczniki zmiany dnia pojawiają się również o północy we wszystkich aktywnych buforach czatu. Zarówno format date_separator, jak i backlog_end można dostosować za pomocą systemu motywów.
Wiadomości backlogu nie wyzwalają podświetleń ani powiadomień i nie są ponownie zapisywane do bazy danych (już tam istnieją). Działa to dla kanałów autoconnect, ręcznego /join, query otwieranych przez przychodzące wiadomości oraz ponownych połączeń DCC chat.
Retencja zdarzeń
Wiadomości zdarzeń (join, part, quit, nick, kick, zmiany trybów) to dane o dużej objętości, które kumulują się z czasem. Ustawienie event_retention_hours automatycznie czyści stare wiadomości zdarzeń, zachowując jednocześnie właściwą historię czatu.
/set logging.event_retention_hours 72 # default — keep 3 days of events
/set logging.event_retention_hours 24 # aggressive — only 1 day
/set logging.event_retention_hours 0 # disable — keep events forever
Czyszczenie uruchamia się przy starcie i co godzinę w tle. Usuwa jedynie wiersze z type = 'event' -- wiadomości czatu, akcje, powiadomienia i CTCP nigdy nie są usuwane niezależnie od ich wieku.
Uzupełnia to ustawienie retention_days, które kontroluje maksymalny wiek wszystkich typów wiadomości. Gdy oba są ustawione, wiadomości zdarzeń są czyszczone przy progu, który zostanie osiągnięty jako pierwszy.
Grupowy zapis (batched writes)
Wiadomości są zapisywane do bazy danych w partiach (50 wierszy lub co 1 sekundę) za pomocą asynchronicznego zadania zapisu połączonego kanałem tokio mpsc. Minimalizuje to rywalizację o blokady SQLite i zapewnia, że interfejs nigdy nie jest blokowany przez operacje dyskowe.