In-line broadcaster chat mod logs


We’ve developed a small update for chat that you might be able to do things™ with if you so choose.

A user will attempt to send listen (with an oauth token) on a pubsub topic chat_moderator_actions.{user_id}.{room_id}

room_id is the user_id of the user that owns the room (in most cases the broadcaster’s user ID).

If that user is the broadcaster or a mod of the room they will receive messages containing a type of chat_login_moderation or chat_channel_moderation as well as some associated metadata about the command used by that mod in that chat.

I highly encourage users here to get familiar with our new pubsub system as we send new types of events through it.

As always, if there are technical questions related to this product, please feel free to ask!

  1. Will there be an API to retrieve these events in non-realtime any time soon?
  2. For 3rd party integrations that store them until 1. is fulfilled; Requiring a chat_login scope from the broadcaster is a bad to awful idea, if any kind of breach happens, potentially hundreds of broadcaster chat_login scopes would be leaked, something nobody could ever want. So using a non-chat_login scope would be great EDIT: nvm, I made a mistake here when doing 2am testing.
  3. Would it be too much to ask the moderator to be added to the IRCv3 tags of CLEARCHAT and ROOMSTATE events? I understand twitch is trying to move towards pubsub for everything, but IRC could use some love
  4. Will there be some documentation of all the events it can send? Otherwise ill have to go through and test all of the cases I might come up with

Good stuff.

So with the current limits of 50 topics and 10 connections, you can basically not read more than 500 logs at a time, correct?
How do we solve that?


Finally you add this!

Waiting for mods also able to know!

I would love to use the PubSub system but when are the topics going to be documented? If they are documented then where? The github page for PubSubs hasn’t received changes in over a month.

@Matrix159 They are documented. The only supported topic for PubSub right now is Bits (and this one). This topic is the latest and will be added to the docs soon. I’m at PAX West so haven’t had a chance to talk with @xangold and add docs.

Thanks - Was just doing some testing, and it appears the message is encoded twice.Is this a bug? Or should we expect to decode the data.message node again in our implementations?


The data message is JSON encoded and the whole packet is encoded.

This has been the same for ALL packets send over pubsub. (Bits etc)

If you get a message of type MESSAGE you get data where the message in that data is the packet of data about your topic. And thus is JSON encoded.

See also the documentation:

So you get a JSON packet that needs decoding which is “what happened” and a JSON packet that needs decoding containing that packet which is a PUBSUB publish

  1. Not soon, but this is something we’re looking into. We’re migrating some legacy systems to newer implementations and will build features once that work is in progress. The API will likely be built to support those features, so would be worked on at that point.
  2. Not lilkely to happen. With CLEARCHAT events being sent to either a room, all sessions of a user, or session specific scope it’s not trivial to allow more specific groups of users to listen to certain information. Basically users could scrape it, and use it to target the mods that timed them out or banned them.
  3. I’ll work with Dallas to determine where and how to document this type of thing. Right now all mod commands that affect users or rooms are recorded. I personally like documenting things that might change after we’ve ensured that it’s not going to change. As small changes usually happen immediately following a release, we’ll usually document it soon after. (excluding a post like the one I made here, which is more of a heads up, than documentation)

I’ll have to look into the limits and see what we can do there. This was not designed for developers in v1 (it was deigned for the site’s use), so there might not be an easy workaround at the moment. Sorry :stuck_out_tongue: Hopefully will have a better story for you at some point.

  1. Okay, nothing unexpected here
  2. Same thing, eventhough it would be VERY nice to have some way of associating the CLEARCHAT with the pubsub message (an ID like chat messages have?). I havent looked into this in detail, are timeout durations and reasons sent in the pubsub message?
  3. He said that earlier, thanks

About limits: these have to be changed, no matter what - as more and more stuff moves/gets added to pubsub, it will get more and more important for large bots to support pubsub, meaning we will have to be able to listen to hundreds or even thousands of topics at some point…

Thank you for your response!

  1. yes

Badly parsed/shown output/ripped from my log follows

This is output result from .timeout REMOVED 1 ASCII Gun

{ type: 'MESSAGE',
   { topic: 'chat_moderator_actions.SOMECHANID',
     message: '{"data":{"type":"chat_login_moderation","moderation_action":"time
out","args":["REMOVED","1","ASCII Gun"],"created_by":"barrycarlyon"}}' }

This is output result from .timeout REMOVED 600 No Kappa Check

{ type: 'MESSAGE',
   { topic: 'chat_moderator_actions.SOMECHANID',
     message: '{"data":{"type":"chat_login_moderation","moderation_action":"time
out","args":["REMOVED","600","No Kappa Check"],"created_by":"barrycarlyon"}}'
 } }

This is output result from .ban REMOVED ASCII 17

{ type: 'MESSAGE',
   { topic: 'chat_moderator_actions.SOMECHANID',
     message: '{"data":{"type":"chat_login_moderation","moderation_action":"ban"
,"args":["REMOVED","ASCII 17"],"created_by":"barrycarlyon"}}' } }

I don’t see for sure how a pubsub message can be tied to a Chat Message ID as in most cases you just write .timeout which doesn’t have a Chat Message context, (bots can self log). And a lot of mods are often advised not to use the mod shortcut buttons in order to avoid misclicks.

The CLEARCHAT message in IRC originates from the .timeout command though, so those could be tied together with an id. The same with other commands/messages, .subscribers creates a notification in chat that Subscriber-Only mode has been enabled, so it would be nice if it had an id that is represented in the PubSub to be able to easier connect who made that notification appear.

By ID we didn’t mean username we meant the messageID that is in the tags of a message.

Yes, exactly. We meant that there could be a messageID on the CLEARCHAT message (and other messages that originate in a command) that would then also be in the PubSub moderation log, so those two infos can be associated with eachother without having to guess which one it is based on the command and parameters. This isn’t about regular chat user messages or user ids.

1 Like

Those messages are not chat messages they are Commands do not have messageIDs, hence they are not included in the current TAGS output of chat.

In theory I suppose a MessageID to represent the PUBSUB message itself would be handy. But I don’t have a use for that myself

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?