Manage the chat monitor externally

[Glodenox]

This might be a bit much, but often when performing room-scale Twitch streaming, you have a technician running the stream, who might also want to manage the chat monitor. In certain situations it might be preferred to hide the chat, for example. It would be nice if the chat monitor can be given certain commands without having to take control of the system. By default, none of this would be enabled, of course.

Some commands I'm thinking about:

• Hiding/showing the chat
• Changing the channel
• Enabling an artificial delay in chat messages (to be implemented still)
• Showing a message on the monitor for the room only

Maybe the monitor can just watch out for certain commands from a certain set of users (or maybe just all mods?). This could possibly be done in a separate channel to hide these commands from the viewers. tmi.js allows more than one channel to be monitored.

Alternatively, though probably overengineered, another WebSocket connection could be made to a command server from which the chat monitor can be managed. The stream technician could run this server locally and have the monitor connect to it. This would probably also require writing an example server. That would be a nice thing to explore, but I'd need to evaluate how likely it would be that someone would use this. Such a server should be able to manage multiple monitors at the same time as well.

[paul-lrr]

I can definitely see situations where this could be useful. Hiding and showing the chat is something we do reasonably often via a wireless keyboard, but doing it via websocket or chat command might be easier. Showing a message on the monitor is also something that could be very useful. During Desert Bus we need a way for engineering to send messages to the room. Usually we use a dedicated monitor, but last DB I actually made a page for our chat display that just used iframes to combine your chat monitor with a text box that the engineers could send messages to. It would definitely be handy to have that all built-in to the chat monitor script.
As for how to do it, I like the simplicity of chat commands not needing another socket server, but it might be a little awkward (especially for the room messages which are not intended for public view). Maybe there is a way to do it via /w whispers to a bot user? Alternatively the socket server could work, especially if it is also able to be configured to connect to an existing socket server on the network. Since the monitor wouldn't really have to send any info back, another option might be to run a traditional server and just take commands via GET or POST requests

[Glodenox]

Thanks for the feedback!

Whispers could indeed work for chat messages, though it would require the chat monitor to be logged into an account. Logging into an account is already possible, but I think using a bot user would probably make more sense here indeed. My initial thought was to have the chat monitor also looking at a secondary channel that is not publicly known. But that isn't really a safe solution, as anyone who discovers the channel can just read the commands then. There's an expectation that those messages remain private, so that wasn't a safe approach.

As for the WebSockets approach: connecting to an existing server is certainly possible as the configuration would request the URL of the server, but then that server would need to support the commands to send to the monitor. If there is software available that allows you to push any command to a server, I guess that should be possible. Running a server at the chat monitor's side doesn't seem practical to me, especially because I want to support multicasting to several chat monitors, and it's easier to configure such a server just once. Having the chat monitor periodically send GET or POST requests to retrieve new commands doesn't seem very practical to me, as that would require a lot more logic at the server end.

I guess I might add support for both methods 😄 Starting with the easier whisper support and looking into the WebSockets afterwards.