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.
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.
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)
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 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)
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.