ChatBridge

One dashboard for every livestream conversation. Unifying TikTok, YouTube, Twitch, and Kick chat in real time.

Comment

Inspiration

I built ChatBridge because I stream to multiple platforms and wanted a simple way to see every chat in one place.

Keeping TikTok Live, YouTube Live, Twitch, and Kick open separately meant juggling several windows or devices while I was trying to focus on the stream. Existing multistreaming tools often charge a subscription, but I wanted something I could run myself, keep open on one dedicated device, and use without paying a recurring fee.

ChatBridge started as a solution to my own setup: one screen, every conversation, no subscription.

What it does

ChatBridge is a free, self-hosted dashboard that combines livestream activity from:

  • TikTok Live
  • YouTube Live
  • Twitch
  • Kick

Messages appear in one responsive feed while preserving their platform, username, badges, color, and timestamp. ChatBridge also displays engagement events such as likes, follows, and viewers joining, along with platform connection health, viewer counts, stream links, and manual reconnect controls.

I can leave the dashboard running on a Raspberry Pi or another dedicated device throughout a stream. A separate feed-only view also works as an OBS browser source or a clean second-screen chat display.

Recent messages are stored in a bounded local buffer and restored after a restart. Short-lived engagement notifications automatically expire so they do not overwhelm the conversation.

How I built it

ChatBridge uses Next.js, React, TypeScript, Socket.IO, and a persistent Node.js server.

Each platform has its own isolated collector behind a shared interface. These collectors convert different platform events into one typed message format before passing them to a central ChatManager.

The ChatManager handles message deduplication, engagement aggregation, persistence, expiration, connection state, and real-time delivery to browsers through Socket.IO.

All connected dashboards share one collector per platform, avoiding unnecessary duplicate connections. Collectors start when the first dashboard connects and stop after the final viewer has been gone for a configurable period. Each integration has independent reconnect and offline-polling behavior, so one platform failing does not take down the others.

I used Codex with GPT-5.6 as an engineering collaborator throughout the project. It accelerated my work when exploring unfamiliar platform protocols (such as websockets), designing the collector abstraction, implementing typed real-time events, diagnosing integration failures, refining the interface, and creating regression tests.

I retained control of the important product and architecture decisions, including self-hosting the application, using a persistent server, isolating platform adapters, limiting stored messages, sharing collectors, and providing an OBS-friendly view.

Challenges I ran into

The largest challenge was that all four platforms expose livestream data differently.

Twitch has established APIs and chat tooling, while YouTube requires discovering the active broadcast before connecting to live chat. TikTok and Kick rely partly on interfaces that can change independently of their documented APIs. Each platform also handles live status, viewer totals, badges, follows, likes, and reconnection differently.

Other challenges included:

  • Preventing duplicate messages and upstream connections
  • Distinguishing an offline stream from a temporary connection failure
  • Aggregating frequent engagement events without overwhelming the feed
  • Recovering cleanly when streams start or stop
  • Preserving recent messages across server restarts
  • Keeping the interface readable on desktop, mobile, and OBS (via /chat path)
  • Testing network-dependent collectors without requiring active broadcasts

The isolated collector architecture became especially important. When one platform needs a fix, I can update its collector without destabilizing the rest of the application.

Accomplishments I’m proud of

I’m proud that ChatBridge became something I can realistically keep open throughout my own streams, not just a technical integration demo.

It includes four working platform collectors, a unified real-time interface, persistent message history, automatic reconnection, viewer-aware collector lifecycle management, health reporting, and an OBS-ready feed.

I also built a hosted demo that lets judges experience ChatBridge without providing credentials or starting four livestreams. It runs through an isolated version of the same collector, ChatManager, persistence, Socket.IO, and interface pipeline used by the real application.

Automated tests cover the central manager, message expiration, aggregation behavior, lifecycle management, and individual collectors. Those tests gave me confidence while improving complicated asynchronous behavior.

Most importantly, I now have the tool I originally wanted: one device showing every place I am streaming, under my control, without another monthly subscription.

What I learned

I learned that displaying four feeds is the easy part. The real challenge is normalizing four inconsistent platforms into one dependable product.

Treating each livestream integration as an independently evolving boundary made the application much easier to reason about. Typed events, explicit adapter interfaces, bounded state, and defensive reconnection logic helped prevent platform-specific problems from spreading throughout the project.

Working with Codex and GPT-5.6 also showed me how valuable an AI engineering collaborator can be when I provide clear constraints and concrete verification targets. It helped me move between architecture, implementation, debugging, testing, and documentation while maintaining a consistent product direction.

What’s next for ChatBridge

I want to continue evolving ChatBridge into a more complete creator and moderation workspace. Planned improvements include:

  • Filtering and searching by platform, user, or event type
  • Highlighting questions and high-priority messages
  • Shared moderation actions and team workflows
  • Stream analytics and post-broadcast summaries
  • Custom themes and configurable OBS layouts
  • Easier guided setup for platform credentials
  • Additional livestream platforms
  • Stronger authentication for public deployments
  • And releasing a public repo so any streamer can self host the project

My long-term goal is to make multistreaming feel like interacting with one community, regardless of where each viewer chooses to watch, without need for a 3rd party or any subscription cost.

Built With

Share this project:

Updates