Hey guys,
I recently implemented chat messages from my extension EBS.
While it successfully works and displayed on the broadcaster channel chat on twitch, we noticed that it doesn’t appear in 3rd party chats (like StreamElements/StreamLabs).
It means that it won’t be shown on the in-stream-video chat, or the StreamElements/Streamlabs dashboard chat, which leads to the streamer missing the interaction most of the time.
Is there any way to make it work on 3rd party chats?
You are better off providing a notification method for broadcasters such as using the Dashboard config panel:
(My panel is in testing here)
As apposed to chat, as broadcasters cannot always see everything in chat all the time anyway, and even if Extension chat, was in chat, they would still miss it.
Extension chat is not relayed over Twitch Chat, so 3rd party clients cannot see or consume them.
Our extension has a notification system implemented in the “live dashboard”.
But we got a lot of feedback from our streamer that they not looking at it most of the time, they are using 3rd party dashboard while streaming and interacting with the chat there.
This is why they requested to add notification on the chat. but now they are complaining that they don’t see it on chat, and they are missing interactions from the extension.
Why does the Extension chat is not relayed over Twitch Chat?
Exactly same issue here encountered for us weeks ago and in fact I wanna elaborate how huge the issue is.
Speaking with a feedback of hundred of streamers I’ve literally talked to. As we all know historically streamers’ default workflow is chat. And I’d say 90% of streamers use 3rd party streaming software like Streamlabs and others for that as part of their bigger setup. Streamers rely on chat for all types of events coming from viewers and now those expectations extend to extensions events. But extensions don’t deiver that by now.
To put this into a bigger picture. Streamers window-shop for extensions (as extensions are not mission-critical by term which is a partly to category branding thing but is out of current topic). So most of them browse Discovery Store, pick one or two, install, some of those would hopefully activate (roughly half of installs won’t but anyway), some activated might configure and customize (most of them won’t). Now those who managed to get through these steps don’t have behavioral pattern to keep extension’s own feed/dashboard open all the time. They simply activate and expect software to do its magic and get notified about it in a way they used to. As any regular user would do.
So now it comes to actual on stream usage. Despite viewers pour bits into an extension the issue of not showing such notifications within 3rd party software ultimately results into content focused streamer missing the extension events. They simply don’t have an opportunity to see if anything happened within the extension. And thus don’t react. Which doesn’t activate network effect from other viewers and on a broader scale leads into bits-enabled extensions perceived by streamers as not delivering any value. Which in turn naturally leads into uninstalls. Which in turn makes no sense for developer to broaden marketing efforts. Which in turn makes the whole thing to develop bits-enabled extensions for broad streamers audience not worth it.
Think of it as if some mobile apps were in fact having their notifications built in but in order to see them user would need to open a separate system default screen buried deep down inside system settings and not on your historical lock screen. Even if there were actual events behind those notifications you would simply not know about those unless you would really wanted to check for them regularly and manually. And why would you if you have your default pattern to rely on lock screen.
I’m not saying devs should not develop their feeds of events, I’m saying most of streamers don’t have a clue on any events due to the issue. And as we’ve discovered it is most likely related to extensions messages not being broadcasted to IRC protocol used by many 3rd party softwares. And before we jump to conclusion it’s their job to support that. 3rd party software devs (sl and others) don’t have any need for our extensions. It’s us and hopefully Twitch who do.
That’s why the issue really needs to be fixed to benefit all of bits extensions. I sincerely hope it will be prioritized as it’s really critical for the whole bits-with-extensions interaction to work.
If you really need an extension to send messages to chat that will show up in 3rd party IRC clients then one option is to simply have your EBS send a message to chat through an actual chat connection rather than going through the Send Extension Chat Message endpoint.
I realise there are both ups and downs to that option, but I’m pointing it out as it is one option to accomplish exactly what the OP is having issue with.
I think we got a little off the initial question.
The Extension messages sent with the chat endpoint are not sent on the IRC channel directly but with another “technology” (I don’t know the specific) that is listened by the website. Why? I think only someone from the Twitch team would be able to answer. It might be linked to username, might be to allow interactive chat messages later (mentioned in the roadmap), etc.
If we really want to send messages to a specific chat, we have to connect a chatbot ourself for now. Things might change in the future but that’s how it is now. You could build your chatbot to just connect to the channel, send the message and leave for example so you don’t have to handle all the incoming messages (just a theoretical idea here)
As part of "sending notifications to the streamers it is quite complex, because every extension requires different things. For example in my extension if the streamer doesn’t answer to the notification in 10 minutes it just goes to expired so I get that problem too.
And honestly I think that we have to ask the streamers and be honest with what we can do technically and see what they want and what they can do on their side because what I see is just “my users said that”. I might have a different approach since extension are side projects for me and I use them to experiment.
We will need a talk about that but not without asking the streamers first. And instead of just “complaining” we could try to find some ideas to improve the dashboard too (And I know a lot about complaining, I’m French).
None of the streams I work with do. I’d be interested to see your metrics here. I actively advise the streamers I work with not to. I have even publicly told SE/SL/others recently and historically of bad development practices but nothing changes.
SLOBS aim is to take people away from the Twitch Dashboard, only problem is everything the Streamer actually needs is in the Twitch Dashboard, sure layout could be a little better and things could be tweaked to be better. But generally SLOBS is just wasting CPU cycles with the extra stuff being bolted onto what should literally just be dealing with Streaming. (Mileage may vary and people often see different results)
Don’t even need to join the channel you can send messages to a channel without joining. (This is the g mode flag on IRC iirc, which Twitch doesn’t use, since it’s not IRC, just a note)
Oh agreed.
Personally if third party chat apps want to see this, a better option is for the third party apps to have a way that we can post data to them (as an extension dev) and it can be entered into events lists to be read, as not all streamers watch chat like a hawk for Subscriptions or tips. Custom Event alerts into SE/SL a better option than it getting lost in chat.
The problem there is how do you, the extension dev, know if a broadcaster is using SE/SL/Whatever, or want to consider/choose to supporting sending data out of a custom event hook.
This also needs to consider that if there is other data relating to the event, x picked this sound they paid y, they also left this message and picked this, but all of this doesn’t fit in an extension chat message so I need to put this in the events thread to the dashboard instead.
There are a number of things which mean using the Twitch dashboard is preferred. Even more so, now that panels can be popped out, streamers can just goto their dashboard, set their title, game, tags and pop open the config panel for your Extension, close the dashboard if they want and away they go.
End of the day using native chat rather than third party chat will always be better due to it always keeping up with any changes Twitch Makes.
I would rather not go deeply into activation and retention numbers publicly but hundred out of our users I’ve talked to were using 3rd party chat software and despite they had in-extensions transactions they simply didn’t know about those. I consider such numbers significant to extrapolate for the whole rather yet small extension ecosystem.
One could convince streamers to use native chat if one works with up to 10 or 20 streamers but while having hundreds, thousands or dozens of thousands installs one just gotta consider this to be a default pattern to deal with. Which doesn’t make se/sl/etc best possible experience but we just gotta deal with that as being significant behaviour.
I hope it’s not a way to solve the issue of being initially notified about something happening and about the fact that you gotta go to the extension dashboard. The reason behind is that to accomplish such deep integration with 3rd parties it would require a lot of clicks from a user to integrate in order to be notified on event while at the beggining user is not quite sure if there’s any value out of extension at all. So putting barriers upfront is not a way to solve notification issue. Install, activate and do its magic. That’s any normal user behaviour.
that might be my mood speaking but I was just expressing feedback and contributing to original issue’s importance with our own experience of loosing installs despite their viewers use the extension.
thank you, Breci! more people experience the issue more likely Twitch product team would notice and take action
I would for sure prefer more straightforward way of notifying all of participants with just one command rather than supporting all of connections for multiple and possibly parallel events happening but thank you for a backup plan, Barry!
@slavasmirnov / @kentasama I want to acknowledge your feedback and let you know it has been received - thank you for sharing your thoughts.
As suggested, Extension chat messages are not sent via IRC and do not currently render in clients that are exclusively reading the IRC feed - this is a known limitation. Without getting into too many details, the Extension chat tech works this way for a few reasons:
There are probably some creative solutions here to solve the 3p client challenge - thanks again for prompting us to think about this scenario as we build out future capabilities within chat.
This is one of the key reasons why I advise streamers not to get too locked in to any third party app, be it for chat or anything else. The more heavily a streamer relies on such software the more likely it is that they will run into issues such as this where new tech isn’t support on their apps, or their apps are slow/unable to adopt new features.
One of the best things for streamers (in my opinion) is to encourage flexibility so that if some app they use doesn’t support new features, such as Extension Chat Messages, that they can adjust and succeed with their streams without that software so that they can best leverage new features that come out to enhance their brand.
@Diogee thank you for throughout answer. Would it be safe to treat one as extensions’ messages with IRC support are not currently being planned or developed?
If so allow me to propose default fallback message broadcasted parallely with full native chat one but to IRC only. Smth like “there’s a notification from extension streamer is using. Use native chat not to miss any”. Thus such would both partially solve 3p issue and serve the goal of moving streamers to native.
In terms of interactive messages. Dope!
@Diogee thanks for shedding some light on how twitch looks at this issue.
I just want to make sure that you are also aware that the live dashboard chat doesn’t display extensions messages on pop up mode, which make the solution of “ask your streamers to use the live dashboard” irrelevant.
Many of our extension uninstalls are because of this issue.
Integrating the extension with the chat is the number 1 request/bug-report we get from our streamers.
@slavasmirnov where you able to implement an IRC based solution?
It is not intended that Extension messages do not show up in Twitch pop-out chat - I will get that prioritized to be fixed, hopefully before the end of March. Thank you for calling it out!
I’d like to add my voice and revive this thread, @slavasmirnov: extension chat messages not being relayed over IRC in exchange for unknown future benefits is Not Cool™, specifically because the default behavior of the majority of streamers does not match up with the interaction y’all have decided on.
If providing a higher fidelity experience incompatible with IRC is the goal, the solution is to 1) relay the normal plaintext messages over IRC and 2) provide an optional payload as an upgrade to that message that can be displayed in high-fidelity on desktop chat. Progressive enhancement is a widely accepted pattern for handling this exact use case. Look to slack for an example of backwards-compatible progressive enhancement for chat messages, specifically.
As it is, the fact that chat messages are only seen on first-party web and mobile clients makes the messages 100% useless for action attribution and streamer notifications. Without a consistent and stable experience for every viewer and streamer, the experience is fragmented and neither the streamer or the viewer can have confidence in their actions. “how do I know the streamer will see me spend these bits on this extension?”, “how do I know that I gave a shoutout to every viewer that gave me bits”. That uncertainty absolutely destroys engagement and confidence in using extensions.
I would highly recommend publishing existing extension messages over IRC, especially since all extensions currently match the format and length requirements of the IRC transport. In the future, providing an additional parameter to the chat endpoint to support high fidelity interactions is backwards-compatible by default.
