Settings and activity
17 results found
-
755 votes
tduva
supported this idea
·
-
11 votestduva
supported this idea
·
-
7 votestduva
shared this idea
·
-
42 votestduva
supported this idea
·
-
9 votestduva
supported this idea
·
-
22 votestduva
supported this idea
·
-
104 votes
An error occurred while saving the comment An error occurred while saving the comment tduva
commented
Please consider this. At the moment we have the absurd situation where an editor can change the stream's tags, but not the title/category.
tduva
shared this idea
·
-
16 votestduva
shared this idea
·
-
33 votestduva
shared this idea
·
-
9 votestduva
supported this idea
·
-
8 votestduva
supported this idea
·
-
360 votes
We're internally investigating live notification management without an expected launch date at this time
tduva
supported this idea
·
-
13 votestduva
shared this idea
·
-
10 votes
An error occurred while saving the comment tduva
commented
With the new emote APIs, this is still missing. Please consider adding this.
An endpoint that allows requesting emote info (such as type of emote, tier, name, set id, channel id, channel name) by emote id. This is useful if all that is known is an emote id, for example from the IRC `emotes` tag.
tduva
supported this idea
·
-
395 votes
An error occurred while saving the comment tduva
commented
Thanks for your reply. A central point of my request is that regular users have access to that information as well, not just with a broadcaster token, which would make it feasible to show poll/prediction/redemptions information for more types of applications.
Whether that information is available through chat/IRC (kind of like it already is for points redemptions with a message attached, although unfortunately with few usable tags about which redemption it is) or websocket, both would be good, but an important part is *who* has access to it as well. Older APIs used to be a bit less restrictive (or of course new features available through IRC), which allows providing all of my users (e.g. mods) with more features, instead of just broadcasters.
tduva
shared this idea
·
-
397 votestduva
supported this idea
·
An error occurred while saving the comment tduva
commented
Sounds good, and it would be even more useful if mods (and regular users, but in this context at the very least mods) could also receive real-time updates on polls/predictions through websockets, so they can see both what other mods are doing and the effect of their own actions. Currently it seems EventSub only supports webhooks, so I'm not sure what category to even post that suggestion in though if it was supposed to be a separate suggestion.
-
75 votestduva
supported this idea
·
To add to this, if an editor prefers a third-party tool (for any number of reasons), then the only way for this to work would be to have the broadcaster grant access to some serverside tool that then uses the broadcaster's token when an authenticated user with access wants to set the title/game. The added complexity of having to handle tokens serverside and having the broadcater grant access when there is no other technical reason for it (for some use-cases that may be required anyway of course) doesn't feel like it adds to security or reliability.
But that aside, having to use the broadcaster token means that the broadcaster's name shows up in the Dashboard's Activity Log for actions that are actually triggered by another user, which seems counterintuitive. This may be unavoidable for some use-cases (e.g. a chat bot allowing mods to change title), but shouldn't be required for use-cases where it makes technical sense to use the editor's token directly (like a clientside tool already using the user's token anyway).