Open y-a-t-s opened 1 year ago
The switch from HTML event bubble tracking to WebSocket jacking should be made before implementing this.
You can add a delay option to .env but I would not use it myself. I like a high synchronicity between chat and stream content.
Good point; the delay is only really necessary for the more censoriously minded. Come to think of it, setting it to 0 by default would likely prevent many headaches for the users.
Recent commits pave the way for this. On Rumble and Kick, moderation events are observable. There's no way way to propagate this but they can be noticed.
47e3e3c14371c0a14f0735f04a2c7b21cd5f1cd3#diff-4e7a84b0c0812fd72544368ce1b3314249b82cb2472a406e56b326aa2520e9f4R134-R140
Creating an issue to track this and discuss approaches.
This is an issue I have been aware of for some time now, but I have held off from doing anything about it until we figure out the direct WebSocket connections. Off the top of my head, we would watch for whatever moderator action info that comes through the sockets and filter out the relevant messages before pushing them to the client.
I propose a split approach where some sort of delay is introduced to filter out messages before they can be pushed to the client and stream. Anything that gets past the delay should still be removed to minimize the time it is visible. We would need to strike a balance where the on-screen feed is not excessively laggy while giving enough time for human mods to act, and allow the user to customize it as they see fit. Alternatively, our community of top minds could always simply figure out time travel.
Edit: And maybe adding filtering using user-defined regex could be cool while we're at it. This allows for stuff like quick filtering of URLs to certain domains.