In-line broadcaster chat mod logs

Re: Message IDs:

Timeouts and bans do not correspond to a message in every circumstance, they correspond to a user. Thus, we can’t garauntee that a target_message_id would be accurate. If we have a product need for adding a different, unique message ID for pubsub messages, we’ll do so at that time. I’m curious what your uses are.

This of course, may change if we allow mods to target a message with a timeout, rather than targeting a user.

UPDATE: We are changing the topic relatively soon, so we can support moderators receiving these messages. You should listen on the `chat_moderator_actions.{user_id}.{room_id} where user_id is the moderator user ID, and roomID is the user_id of the channel/user.

Currently we are sending both, but will cut off the older topic in favor of the new one at some point.

We are not talking about associating Timeouts/Bans with a chat message, but associating them with their PubSub message.

For example:
@ban-duration=1;ban-reason=;id=abc CLEARCHAT #tduvatest :tirean


Using that id, it would be possible to know which CLEARCHAT belongs to which PubSub Moderator Action (without having to guess based on the command and parameters), so that messages can be displayed more compact, for example:
Tirean: <message deleted> (1s) (by tduva)

Instead of two separate messages:
Tirean: <message deleted> (1s)
tduva timed out tirean for 1 seconds.

This also applies to other messages, for example:
Exited host mode. (by tduva)

Exited host mode.
tduva used unhost

Since both the chat message (CLEARCHAT, NOTICE) and the PubSub Moderation Action originate from the same command that a mod typed in, there is a clear relationship that could be expressed by an id.

Gotcha. I think we could add a related_clearchat_id or something similar if enough value in it is seen.

In our version of the product, we entirely ignore the duplicate messages if you would be eligible for the upgraded messages. This way, you only ever see the message containing moderator information. That solves the specific issue you are discussing, but there might be other circumstances where you’d want to know which timeout caused both.

Can you chuck in a timestamp?

Er is that much different than a client-side time-stamp when it receives the event? I imagine this is for ordering purposes, or what? We try to keep events as small as possible to limit maintenance, and to keep performance high.

Events should be received as they get sent through, and a timestamp might be slightly different depending on which server handled the request (though we use ntp and theoretically shouldn’t be clock drift)

A server time stamp would be nice, but I/we can get by without.

I setup logging myside and completely forgot to stash a timestamp with it myself

Any idea when this will be documented? Also, for moderators wanting to connect, what scope do we use?

This thread is the documentation so far.

You just need a valid oAuth key for the user_id you wish to connect as, the minimum scope to get the user_id from the API is user_read but I have not tested a no scope key, coz no one ever makes those Kappa

Ah, thanks - from what I’m seeing, you can only get logs for one moderator at a time? So you have to watch them all individually?
EDIT: Never mind :smiley: The listen just confused me. Thanks for the help!

You “login” to pubsub and say “I’d like to connect to this room_id as this user_id identified by this scope” and then you get a feed of ALL moderator actions that all moderators do (including the broadcaster)

(Replied for clarity)

Just thought I’d mention that a no-scopes key works just fine!

Know when this will actually be documented on ?

A message ID would be useful for deduping events received on multiple sockets (during reconnection, etc). Also, do we have a solution for listening on more than 500 channels (10 connections, 50 topics per connection, 1 channel per topic) yet? I’m hesitant to build features of my bot on top of pubsub until we will reasonably be able to scale past 500 channels.

For everyone who would like to test it: I built a small application that simply displays the bans, timeouts, unbans:

1 Like

My mistake, forgot that this current set up was currently enabled for broadcasters only - my error!

But still just a general heads up for people to not hand out stream key willy nilly (or at least make sure you reset it afterwards)

Looks like this is NOT for broadcasters only. I see these logs when using chat_moderator_actions.channelId.roomId as a regular moderator as well!

Please note that it is not channelId.roomId but it is chat_moderator_actions.<my userid>.<channel user id>

Ah yes, I haven’t kept up with pub sub so I thought Xangold’s post still reflected the current state (broadcaster only) - good to know its not :slight_smile:

My bad! Updated post to reflect the current state.

No worries, I should have done more investigating before replying :slight_smile: Thanks for updating @xangold!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.