Experimental Stream Chat Implementation

[sleroq]

Hi! Thank you for creating broadcast-box, it's really nice.

I played around a bit and implemented a chat feature my friends wanted. It's currently working only with my client at https://web.cum.army. Video demo. You can check out its source code at https://github.com/sleroq/web.cum.army.

I don't expect you to merge this, as it's more code to support. I just want to share this with you. But if you like it, I am happy to apply any suggestions and update the frontend as well.

Outdated overview

Technical Overview (generated by gemini)
The implementation follows the existing patterns of the project (plain Go net/http and SSE) to keep dependencies minimal:

• Transport: Uses a "Connect -> SSE" flow. Clients exchange a streamKey for a chatSessionId via POST, then subscribe to an SSE stream. This avoids the browser limitation where EventSource cannot set custom Authorization headers.
• Reliability: Supports the Last-Event-ID header. If a client disconnects, they can reconnect and automatically receive missed messages from the buffer.
• In-Memory Storage: Stores a ring buffer of the last 10,000 messages per stream (configurable).
• Lifecycle: Includes a 72-hour TTL for idle rooms and sessions to ensure memory remains bounded.
• Keep-alive: Sends a : ping comment every 20 seconds to keep connections alive through proxies/CDNs.
  API Surface
• POST /api/chat/connect: Returns a session ID.
• GET /api/chat/sse/{sessionId}: Streams history and message events.
• POST /api/chat/send/{sessionId}: Broadcasts a message to the room.

Thanks again for the great project!

[sleroq]

The React-side implementation is pretty simple. Most of the logic for handling the SSE stream and message state is contained in this commit: sleroq/web.cum.army@2c719a2.

Beyond the chat, I've a added other quality-of-life improvements to the frontend on my fork. If you have a few minutes, I'd love for you to take a look!

If someone likes it - I'd be more than happy to split them into PRs and contribute them back to the main repository.

[Sean-Der]

This is amazing! Thank you @sleroq I think we should merge this. Broadcast Box started as a 'Get WHIP merged into OBS project', but now that it is generally useful I want to get stuff like this merged!

I am traveling today. Then I will work on getting this in :)

[sleroq]

@Sean-Der I'm going to contribute frontend side in a separate PR today/tomorrow.

Current limitations:

• No persistence, messages are stored in memory
• This won't scale memory wise
• Each chat participant maintains an open HTTP connection
• No auth / moderation / rate-limits

Some questions:

• Should chat endpoints be disablable via env?
• What do you think about frontend features of my fork (webrtc reconnect, ui, eslint config, themes, etc), should I port them?
• Should we refactor the code so we don't call Getenv in different places and instead build config on start?

[Sean-Der]

I am so sorry about all the churn @sleroq. I really wanted to get a fork of Broadcast Box merged in, turned out to be more work then I anticipated :)

Would you be interested in being added as a admin to this repo? I understand if you are hesitant, but this is what I see.

• You are using Broadcast Box actively, your ideas are super valuable.
• Your code is high quality. You updated docs
• Your communication excellent. Often I get no responses or zero empathy/understanding for other users.
• You are persistent. Most people open PRs and then never respond

So if you are up for it I would love to work together with you. I would add you as admin and would love to hear where you think the project should go. I think it has so much potential, but I am not going to be able to achieve it on my own :(

[sleroq]

@Sean-Der

Thanks for the kind words, appreciate it. Yes, I'm down to be added as admin. Happy to help push things forward and share where I think the project could go.

[Sean-Der]

Done! You are an admin @sleroq

The SSE isn't something we should modify (if possible) the SSE events come from https://www.ietf.org/archive/id/draft-ietf-wish-whep-03.html

Would it be possible to Send/Receive messages via DataChannel instead? We should move the status/count to that as well. The goal should be that any standard WHIP/WHEP client works with Broadcast Box (FFmpeg/GStreamer)

If you are up for it we should also move the stream status and other stuff off of SSE. I just haven't had time yet :(

[Sean-Der]

@sleroq do you want to rebase and land or I can! I have time tonight

[sleroq]

@Sean-Der

Would it be possible to Send/Receive messages via DataChannel instead? We should move the status/count to that as well. The goal should be that any standard WHIP/WHEP client works with Broadcast Box (FFmpeg/GStreamer)

Sounds good. Will ping you when I have something to review.

[Sean-Der]

Hey @sleroq!

I have the day off today. I can do the rebase, I can take it on! Unless you have started already.

[sleroq]

Already started working on this, need to test a bit more and I will push it in a few hours. @Sean-Der

upd: small delay, need to make sure it's right

[Sean-Der]

Hell yea, amazing @sleroq

After this lets do a 'big release' with profile + chat and this is the time to get people off non-free solutions :)

[sleroq]

@Sean-Der

Updated branch to use DataChannel and refactored a bit.

The current implementation isn't perfect and I'd like to improve it further, but I stopped myself from adding too much so it's easier to review. I plan to add more features separately.

Planned improvements in separate PRs:

1. Chat backfill & long history

Currently when a client connects, we send the entire chat history to them. It's fine overall, but with large chats it'll be too much data. I'll implement proper backfill to avoid sending everything to the client.

2. Redis/SQLite db support

On my fork I already got irritated by losing history on each release, so I'll add a Redis storage option (default stays the same so it's easy to set up and Redis is not required). This is the reason for the storage abstraction.

What do you think?

[sleroq]

I have frontend implementation almost ready, you can test it here - https://github.com/sleroq/broadcast-box/tree/chat-web

Can't open chain of PR's here because it's external branch.

[Sean-Der]

Hell yea, will merge this tonight! Great job @sleroq

If you have any other improvements/ideas would love to get those merged also.

[Sean-Der]

@sleroq

Thanks for making the PR manageable! Was very easy to read :)

Chat backfill & long history

SGTM!

Redis/SQLite db support

Great plan! Maybe we can tie into webhooks somehow? I want to make the code as easy as possible to deploy.

[Sean-Der]

Nice work! Merged, I want to explore some changes but those can all be done after landing.

• What do you think of removing the name room? It only appears in internal/chat/store_in_memory.go and would be nice to keep things at just stream/streamKey so people don't get confused.
• Rename ts to timestamp. Just to be as verbose as possible/make it easier for others to read.
• Don't use dedicated loop for cleanup. Hung/broken threads are a major source of bugs. If we can do cleanup on send/receive makes things easier to reason about.

I also want to explore do we need dedicated state just for Chat? Could ChatManager operate directly on WHIP/WHEP Sessions? If we added an interface ID and Send we could just iterate existing sessions and not keep double state. I am just looking for ways to aggressively delete as much code as possible :)

If you are up for exploring/make these changes I would love that! If not tell me and I can take them on tomorrow

[Sean-Der]

Also I want to explore making this as general as possible. Some users will want just generic pub/sub for messages.

I think how you have chat today is REALLY close to that, but you want

• Historical Messages
• Custom Validation/Modification

Luckily we have the DataChannel label (thanks for doing that!) how much logic can we move into the clients? That lets/encourages people to do custom clients and Broadcast Box server can be used for as much custom stuff as possible.

[Sean-Der]

Hey @sleroq

I am going to work on ^ and when done will merge the UI code you have been working on. Thank you so much for everything you have done :)

[sleroq]

@Sean-Der Sorry if I move too slow, trying to find time for all of the projects. Will make PR with UI today, and I have more UI improvements planned this week. Hopefully will get this done before the release.

Thank you for guidance and kind words!

[sleroq]

Also I want to explore making this as general as possible. Some users will want just generic pub/sub for messages.

I understand this, we need to keep minimal client implementation simple, tracking history and backfilling should not be necessary.

I plan to make example OBS plugin for the chat. Will make sure you can just connect and pull new messages without handling any backfilling.

[Sean-Der]

@sleroq amazing! You aren’t slow at all.

I’m used to people getting PRs in and then disappearing. I don’t take it personally at all.

[Sean-Der]

@sleroq I I am totally fine with history + backfilling being in the code base.

If you put it in the backend means you don't need to put it in every client. After you merge the frontend I will work on some minor modification of backend code (that doesn't break the frontend in any way)

no rush!