Moderation Action PubSub topic only works on own Channel?


#1

The moderator actions PubSub topic is now officially documented as chat_moderator_actions.<channel ID> on the PubSub page https://dev.twitch.tv/docs/pubsub however it looks like it only works on my own channel?

If I try it on another channel I’m modded in I only get ERR_BADAUTH. The account of the token is a moderator in said channel and has scope channel:moderate like the docs say (and also chat_login).
Is there any way to get that to work on any channel I’m mod in and not just my own?

I know there’s the undocumented previously recommended topic chat_moderator_actions.<userid>.<channelid> which seems to work (when using it with an official Twitch token at least, it doesn’t look like it works with a normal OAuth token with just channel:moderate scope either) but I’m just curious if the now officially documented topic is supposed to work on other channels where you’re modded somehow or if I’m doing something wrong? Just because using the official one seems nicer.


#2

Yes it would appear that having moved the topic into official support, it was also updated to be more in line with current methodology and scoping.

To monitor all moderator events you need to use the new “channel topic” with an oAuth provided by the broadcaster.

It seems that it is no longer supported (technically never was) for you use get this data when authenticating as a moderator.

Changes/it being documented originally covered here Upcoming OAuth scope requirements for PubSub


#3

That sounds quite worrying. Moderators need to be able to know what other moderators are doing. This would greatly reduce the usefulness of third-party modding tools.


#4

You can still pull similar data from Chat (User)Notices. PubSub is just scoped behind the broadcasters permission granting now


#5

Which chat messages tell me which mod performed what action? The ban/timeout reason? When another mod unbans someone? Scoped behind broadcasters permission is exactly the issue here, if it means that this kind of information is not available for moderators anymore.


#6

shrug it’s now up to the broadcaster to delegate that permission. And it’s still working “as expected” in vanilla chat.

Yes it’s an annoying change. But it is what it is. Now that the topic is officially supported by third parties we can ask for things to be added to it. But depends what Twitch’s end goal is here since the initial official support is to gate it behind the broadcasters oAuth.

Yeah I forgot that most of the sensitive data is stripped on the feed now (who did what etc).


#7

A change like this also wasn’t announced, so it comes as quite a surprise to me. From the thread announcing the added scope requirement:

Note that chat_moderator_actions was not formally documented other than within this discussion, however, it will require a new scope as indicated above. This topic should be considered officially supported.

That doesn’t show any indiciation that it is being changed (apart from the now required scope), since it refers to the topic as it was discussed before. It certainly doesn’t mention it being restricted to the broadcaster. It by the way also doesn’t mention who the token has to be from on the PubSub documentation.


#8

Twitch are not obligated to announce changes related to undocumented things.

An already filed docs bug - https://github.com/twitchdev/issues/issues/25


#9

Of course they can do whatever they want with their platform, however communication is still important. In some cases it is done very well and I appreciate it. The shutdown of v3 for example seemed very well performed. I was just explaining why I’m even more surprised by this when they (seemingly) announced that the already existing topic was now officially supported, not a changed topic.


#10

Won’t this affect the ability to approve and deny messages that get flagged? I’m pretty sure that fell under the same pubsub topic


#11

Vanilla Twitch/automod functionality is unaffected by this change, which only affects third parties.


#12

Right, I get that the normal site will still work. I guess I’m just frustrated that I as mod, and I assume many others of my kind, have specific tools written to help us with our task that go beyond what Twitch provides, and that now much of that functionality will be useless.


#13

I converted all the tools I wrote that the mods whom work with me/the broadcasters I work with use, to use the broadcasters authentication/oAuth on the new official topic without issue. Given for the most part I already had the right oAuth key(s) with the right scope(s) on already.

Course we have centralized tooling to the channel(s) so making a fix so it works for all the mods is straightforward.

Talk to your developer, or if it’s you, and just update the programs you use (if you can), or write new tools.


#14

If you’ve been using undocumented endpoints then that is one of the risks you take, things can and will change or be removed at any time and without warning.

If you want to continue using the topic then you’ll have to use it as intended, with the broadcaster granting you a token with the appropriate scope.


#15

This isn’t just about undocumented endpoints, really. Twitch doesn’t tell us about any changes anymore. Twitch needs to speak up when they change anything related to their API endpoints period. The silence every time something breaks/changes is straight up frustrating to deal with.


#16

Looks at announcements
Yeah, they’re certainly not telling us about any changes any more, like the upcoming change to OAuth requirements in Helix, or embeds, or the changes to parts of the v5 streams and followed endpoints… Oh, wait that’s exactly what they’ve been informing us about.

What specifically are you referring to? If you mean the v5 /streams/followed endpoint having a different sorting, well there was no documented sorting to begin with, the issue is with people making assumptions about how data is going to be presented to them when Twitch in no way guarantee it in any certain way with that endpoint.

Or are you referring to Twitch putting further restrictions on undocumented endpoints because they are unsupported and were never intended for 3rd party use? As has always been said on this forum, if you use undocumented endpoints you use them at your own risk, and at potential violation of the developer agreement. Undocumented endpoints can and will change/break at any time and without warning, so those who use them do so knowing full well it’s their own fault if they utilise them in production and their app breaks due to a change.


#17

That is what I’m talking about, and it’s been that one way for YEARS. They changed it without saying a word which breaks things for many people. It’s quite obvious that it was intended to be sorted that way always as they changed it back in the end.


#18

The API is a constantly evolving thing, and for things which have been specifically documented to work a certain way then Twitch are good at responding to either intentional changes to that, or bugs which can be fixed. For things that aren’t documented or guaranteed to work a certain way then things can change without such responses from Twitch.

As a 3rd party developer it’s best practices to work within the bounds of the documented API if you have strict uptime requirements to keep in a production app, the more assumptions you make, or undocumented endpoints you use, the more at risk your app is to use in a production environment.

Anyway, this has gone offtopic now so if you’re unhappy with Twitch’s response, feel free to submit a support ticket.


#19

This wasn’t an assumption. When something has worked one way for years, we know that it’s supposed to work that way. When Twitch doesn’t say anything when changing things, we have no clue that they’ve broken an endpoint for us. Again, it’s extremely obvious that it was always intended to be sorted this way as it was only not sorted this way for literally 2 days out of its entire multi-year existance.

And my main point is that the lack of communication makes developing anything related to Twitch’s endpoints an absolute nightmare.


#20

Yeah but that was a private not documented endpoint, if you want stability just stick to the official ones and you’re mostly fine. They’ve been pretty good about documenting official API changes well in advance, only thing I remember them breaking recently was the silent Clips API changes.