Whispers on IRC 3: Just when you thought it was safe to chat

Alright, I guess Twitch staff don’t want to discuss this, but let’s try again with a different format.

Can someone please explain to me:

  1. Why Twitch has chosen to implement “whisper” functionality - basically an equivalent to IRC’s /notice feature - using a new, non-standard message instead of said /notice feature
  2. Why they’ve “purposely made whispers convoluted for IRC integration” (their own words) by using a non-standard message type and alternate servers (even just supporting this feature on the main servers would make it really easy!)
  3. Why they plan to move this feature to some new protocol instead of using the existing IRC functionality
  4. What current IRC users are intended to do to avoid missing these messages directed at them in the meantime
  5. What developers of bots and third-party chat clients are meant to do
  6. Why this seems to be such a sensitive topic

So far the only answers I’ve got to all of these questions are “IRC is not an appropriate technology for providing these features”, where “these features” are completely unspecified. Aside from not answering the question at all (what do these other features have to do with this existing feature?), Twitch staff seem completely unwilling to discuss what these “new features” are and why they can’t be implemented via IRC (making third party devs’ lives easier).

In any case, these plans to introduce some unspecified “new features” really don’t have anything to do with the questions I’m asking here, about a feature that exists now and can be implemented easily over IRC (or if not, can someone explain why?). Whether other, future features can be implemented via IRC is irrelevant.

Twitch seems to be making an active effort to support third party developers, except in this case. It’d be great if someone could explain the reasoning behind this bizarre decision instead of just giving another dismissive non-answer and another locked topic.

Some guesses:

  1. One of the reasons can be that NOTICE is used for some other stuff (by or ) which required some changes on its handling via IRC server which can cause malfunction now for different clients users.
  2. If you are just a user of some 3rd party client - deal with it and wait for update, but if you are a developer (REAL developer with powerfull client) - there are some ways to impelemnt it and they arent THAT hard to complain about it. (Maybe that looks easy for me cause i am dealing with group chats a lot right now for my bot, but anyway its not harder then “average”)
  3. Because they want more then just sending a message user-to-user?
  4. Have some empty channel opened in browser to see it?
  5. For clients - as i told its not that hard, if you are REALLY a developer. And you can make some temporarily solution due whispers going to be changed.
  6. Cause there are a lot of discussions in deifferent forums\channels, probably you missed something but one of the key things is that developers are restricted by employer in revealing stuff.
  1. A user-to-user chat has many uses, I don’t think that is what you’re disputing. I’m pretty sure they aren’t planning on this to be equivalent to IRC’s /notice. If that’s all they wanted, they would’ve used it.
  2. They’ve released a prototype that runs on IRC and they’re obscuring it on purpose to emphasize that developers shouldn’t spend hours of work on a prototype API. Read the answers of the staff, this should be pretty easy to conclude.
    Releasing a prototype allows them to get data and opinions on the system, which helps them shape the eventual protocol and format.
  3. Lots of reasons, see below.
  4. I agree that this is a very unfortunate side effect, and I’m sure that others agree.
  5. Wait for the eventual full version of the system. I think the feature maybe should have been better communicated as a beta feature.

I think it’s best to see this system as a new messaging system, the use of the chat box is for convenience, and the use of IRC is to make the prototype easier to deploy/develop.

Note in the announcement:

Offline delivery, popout instant messages, and more! [src]

A new protocol would allow better integration for things like push-messages to mobile, dedicated, persistent chat windows for each user you talk to, with possibilities of loading history using cursors or offsets for API calls. Use of commercial-scale push-type systems, such as Firebase. Give me some more time and I’ll come up with more reasons, but any of these would probably be enough.

Having a modern, flexible API for a persistent messaging system is far more appropriate than inventing new functionality inside a protocol built for something entirely different.

1 Like

Reading my last reply to you in the previous whispers thread, I realize I came off as dismissive and vague. That wasn’t my intention, and I apologize.

In addition to the other excellent replies in this thread, I’ll try to shed some light on our product development process. Our general approach to product development is to start off with something simple, get feedback from our users, and use that feedback to rapidly iterate on features to gradually arrive at the best possible user experiences.

In order to learn from our users as much as possible as quickly as possible, this often means making short-term tradeoffs. In the case of whispers, this tradeoff appears as a tension between what’s easiest for third-party developers and what lets us iterate as quickly as possible. We made sure to implement whispers as a feature that third-party developers can still build on top of (and there are already several bots which utilize them!), though the implementation may not be as convenient as possible.

For instance if we were to use NOTICE for whispers, we’d have had to implement a custom tag or something similar to differentiate a whisper from a regular NOTICE (which we use for slowmode notifications and such), which means our clients would need additional, messier logic, which ultimately ends up with us moving slower.

As our products mature, we’re able to increasingly spend time in optimizing our API for third-party developers. This, for instance, is what we’ve finally begun to do with our IRC protocol after two years of focusing on reliability and general chat improvements. We’ll get there with our other features as well, but it takes time and tradeoffs along the way.


Personally I’m glad Twitch is doing it like that, and like in this case, not letting 3rd party IRC clients (that are not even intended for Twitch) constrain the features that are added to Twitch.

If we actually do see rapid iterations then the usual pains of 3rd party development, I hope, will become easier when our feedback can be taken into account. In the past version 1.0 of Twitch’s features have always been very restricted for anything outside the intended purpose, but with rapid iterations then those can be made more reasonable through feedback, and not set in stone and moved on from like it has in the past.

1 Like

Thanks for the helpful replies and not just closing the topic this time.

The current implementation does make more sense if the whisper feature itself is considered beta/testing and might change significantly in the near future. The impression I got was that the feature itself was more or less finalized and only the underlying protocol was planned to change.

Certainly if the feature itself is considered to be in testing and likely to be changed or replaced then I can understand not wanting developers to build upon it. My case is a bit different though, as a developer of a chat client; my goal isn’t to build new functionality based on existing features, but just to ensure that all those features are as accessible as possible to users. Whether they’re in beta or not, I want to ensure that they’re available, so that users aren’t missing messages and feeling left out of the neat stuff everyone else is getting.

I still think it’d be helpful for third-party developers if this and other future features were, at least optionally, exposed via the standard IRC interface. (In fact there are some existing features I’d love to see added to IRC, like mapping stream title to TOPIC messages, broadcaster/mod/staff/etc to user MODEs, etc.) It would make development of chat clients, bots, and other tools simpler. (Currently my script makes several API calls for various events, which is a lot of overhead. Some of them can be removed now thanks to IRCv3 tags, or at least they can once HexChat allows those to be read by scripts…)

For example, it should be possible to implement whispers as sender NOTICE receiver :message; since existing NOTICEs only (as far as I know) come from jtv and twitchnotify, there shouldn’t be any collision with those (and a message tag, like the message ID tag already in use, can help distinguish them). Or they could be implemented as sender PRIVMSG receiver :message (how private messaging usually works on IRC) or even sender PRIVMSG channel :receiver: message (as was previously done with some jtv messages, tying the message to a channel, which would be more helpful for bots).

(Also, if it were possible to send them by sending W receiver :message instead of only PRIVMSG #jtv :/w receiver message, most clients would be able to send them without any modification, since most will send commands to the server if they don’t understand them themselves.)

Other future features such as offline delivery could be implemented in similar ways. I feel like this could be an appropriate compromise: provide whatever API/protocol is most appropriate, and also provide a CAP for IRC clients to request these new features. That way there’s no worry about constraining those features based on IRC limitations (and with CAP you’re free to use non-standard protocol extensions, since a client must explicitly request them), and if IRC isn’t suitable for the feature, it can be provided in a more limited form or not at all.

A lot of people who use IRC like the simplicity and flexibility - plain text messages, control over windowing and formatting (many use it in a text-only terminal), scripting capability, etc. Those users might not necessarily want things like pop-out/persistent chat windows; they’d rather choose on their own whether to move things to separate windows and how to manage them. On the flip side, some people use it because the web chat isn’t accessible*. Those users typically want the same features and experience they’d get with the existing chat, so the more a developer can provide them, the better.

(* I personally use IRC because I hate Flash, and dislike the amount of padding and large “send” button the web chat has. I watch Twitch on my Android tablet, and IRC lets me also use the chat on my PC while the tablet plays in fullscreen. Friends of mine have similar setups because their computers are too old to handle Flash video streaming, or because they want to idle in a lot of chat channels, for which IRC clients provide a more convenient interface than popout chat windows. Some of them use scripts to alert them to potentially interesting messages or even read them out loud.)

Anyway, thanks for offering some more helpful answers, even if I was a bit stubborn about it. :smile:

Yeah, a small chat column next to video looks poor and unusable after huge chat window and customization at IRC client :smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.