Inboxless LiveChat (pomysł)

05 Jul 2026 w Notatki tagi: it

Pomysł na self-hostowany live chat, który działa bez dedykowanego panelu obsługi – wiadomości ze strony obsługiwane bezpośrednio w Google Chat (lub innym).

To pomysł na self-hostowany widget live chat, który nie potrzebuje żadnego dedykowanego panelu do obsługi rozmów – wiadomości ze strony lądują w twoim chacie. U mnie jest to google chat

Na razie to wyłącznie czysty pomysł - coś w rodzaju publicznej notatki.

• Punkt wyjścia
• Dlaczego nie gotowe rozwiązanie
• Pomysł: Google Chat jako panel
• Jak to ma działać od środka
• Status prosto z czatu
• Panel konfiguracyjny
• AI jako asekuracja, nie zamiennik
• Stan projektu

---

Punkt wyjścia

Każdy live chat, na jaki trafiłem, ma tę samą wadę: kolejny dedykowanny panel do osbługi chatu na stronie.

Do tego doszła druga myśl, przy okazji rozkminiania architektury Durable Objects przy wyslij.link – skoro ten mechanizm tak dobrze sprawdza się do przesyłania plików między dwoma urządzeniami bez pośredników, to czemu nie miałby zadziałać do czegoś zupełnie innego – rozmowy na żywo z kimś na stronie. Do tego istnieje wiele projektów chatroom’ów stworzonych na cf DO.

Dlaczego nie gotowe rozwiązanie

Zanim zacząłem cokolwiek rozrysowywać, oczywiście sprawdziłem, czy ktoś już tego nie zrobił. Tawk.to jest darmowy, potrzebuję osobnej aplikacji. Chatwoot jest open-source, ale znów dostajemy kolejny panel do obsługi.

Pomysł: Google Chat jako panel

Ju od dłuszego czasu mamy wdrożonego bota w Google Chat, który informuje nas o nowych formularzach ze strony. Działanie tego jest neizwykle satysfakcjonujące. W tamtym przypadku Appscript przesyłą podsumowanie formularza do chatu w ładnie sformatowanej formie.

Cały koncept stoi na jednym założeniu: operator nie potrzebuje niczego nowego. Rozmowa ze strony ma zamieniać się w zwykły, nowy wątek w Google Chat. Odpisuję tak samo, jak odpisuję na każdą inną wiadomość – bez przełączania się do żadnego dashboardu.

Docelowo architektura mogłaby być na tyle uniwersalna, żeby dało się podłączyć też inne komunikatory – jedyny twardy warunek to możliwość rozdzielenia rozmówców analogiczna do wątków w Google Chat.

Jak to ma działać od środka

Punktem wyjścia jest ten sam duet co przy wyslij.link – Durable Objects i WebSocket – tylko wykorzystany inaczej. Tam obiekt znikał razem z zakończeniem transferu. Tu ma żyć jako trwały pokój rozmowy, z całą transkrypcją zapisywaną we wbudowanej w niego bazie SQLite.

Przy starcie rozmowy dzieją się trzy rzeczy naraz:

1. Powstaje wpis w D1 – identyfikator rozmowy, podstawowe dane klienta, powiązanie z konkretnym wątkiem Google Chat.
2. Powstaje dedykowany Durable Object tego pokoju.
3. Powstaje nowy wątek w Google Chat, przez oryginalne googleapis uruchomione na Cloudflare Workers (jest na to niezły przepis od kogoś, kto już to ogarnął). Klient dostaje identyfikator rozmowy i zapisuje go w localStorage – dzięki temu wraca do tej samej rozmowy nawet po zamknięciu przeglądarki, nie tylko po przejściu między podstronami.

Odpowiedź wraca odwrotną drogą: piszę w wątku Google Chat, Google wywołuje webhook na Workerze, ten po identyfikatorze wątku znajduje właściwy Durable Object i wypycha wiadomość przez WebSocket z powrotem do klienta.

Całość w skrócie wygląda tak:

      POST /start (roomId)
KLIENT -------------------------> +---------+
  |                               | WORKER  |<----> GOOGLE CHAT(app)
  |                               |  + D1   |
  |                               +----+----+
  |                                    |
  |                               binding
  |                                    |
  | WS /ws/:roomId                     v
  |<----------------------------> +----------------+
                                  | DURABLE OBJECT |
                                  | pokój, SQLite  |
                                  +----------------+

Status prosto z czatu

Przełączanie dostępności ma działać bez wchodzenia do żadnego panelu – wystarczy wpisać /offline albo /online bezpośrednio w Google Chat. Panel konfiguracyjny (/dash) ma tę samą funkcję jako alternatywę, ale codzienne przełączanie ma się dziać tam, gdzie i tak jestem + może harmonogram oparty na standardowych godzinch pracy.

Panel konfiguracyjny

Wspomniany panel /dash będzie być wizualnym interfejsem administracyjnym, aby skonfigurować ustawienia aplikacji to jest klucze do chat, dozwolone domeny, turnstile i inne ustawienia. W idealnej implementacji całość powinna dać się uruchomić przy pomocy “deploy on cloudflare”. Po zabezpieczeniu endpointu /dash przy pomocy cloudflare access naszym oczom powinien sie ukazać panel konfiguracyjny ktry przeprowadzi nas przez wszystkie kroki. Niestety połączenie z google chat będzie najbardziej skomplikowane natomiast będzie to koszt rozwiązania do samodzielnego hostowania.

AI jako asekuracja, nie zamiennik

To ju bardziej odlegly pomysł na ewentualne kolejne iteracje, ale zostawiam sobie miejsce w architekturze: gdy status jest offline, prosty model mógłby zbierać od klienta podstawowe informacje – nie po to, żeby rozwiązać sprawę za mnie, tylko żeby po powrocie online mieć gotowy kontekst zamiast pustego wątku. Wystarczy, że sam odpiszę w wątku, żeby przejąć rozmowę z powrotem – żadnego przełącznika, żadnej dodatkowej czynności.

Stan projektu

Na razie to wyłącznie rozpisana specyfikacja – architektura, schemat bazy, itd. Traktuję to jako projekt do rozkminiania łączenia systemów real time.

Jeeli to jest dla Cebie ciekawe, daj znać :D