To give more freedom in using Bits, having a Bits escrow system would be great.
RFC0011 ( https://discuss.dev.twitch.tv/t/rfc-0011-extension-entitlement-service/19142 ) introduced that idea but was never implemented.

What would be the possible flows:
- A viewer sends Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- After some delay, the Bits are refunded to the viewer because the transaction was not validated.

-- Viewers send Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- The Extension backend send a cancelation order to Twitch, canceling the Bits transaction.
- The Bits are refunded to the viewer because the transaction was not validated.
- If the transaction is not canceled, the Bits are sent to the streamer after the cancelation period expires.

In a practical way, it would be nice to have a way to cancel a Bits transaction before a certain limit of time.
This way we can create experiences that are safer for broadcasters and viewers because they are guaranteed to have the Bits used only when the conditions are met.
We could also use this system to handle server-side errors to refund people that used Bits something went wrong.

I was thinking, not all extensions need to be tried to a specific channel experience, and don't always interact with the broadcaster at all. Extensions like the chat translator, or maybe a TTS chat for viewers who can't read well, or visually impared, it would be great to have for users on every channel, not just channels where the broadcaster decides they want to use it. My idea is to have extensions that the view can enable on every channels, and possibly have the panel for viewer extensions be where the chat is, and possibly take up the bottom half of the screen, but same dimensions at chat, so you would have the top half of the screen be the chat, and bottom be the panel, or in a case like the translator, allow the viewer to have the panel take up the full height of chat. then the user can switch between their extensions similar to the experience on the streamer dashboard, and the drop down will be able to cycle through the extensions installed, so you can have multiple extensions running on every channel you visit.

An update on Jan 31, 2019 gave channel moderators the ability to add comments to users within chat. There is currently no way to use the API to be able to set or retrieve comments for users in chat.

This should be available to the broadcaster and all moderators within a channel.

To add a mod comment to a user, the endpoint could take the following data as inputs:
- User: {user's name}
- Moderator: {mod's name}
- Broadcaster: {broadcaster's name}
- Comment: {comment to be applied}

On success, this would return the following:
- Success: {true}
- date: {date}
- User: {user's name}
- Moderator: {mod's name}
- Broadcaster: {broadcaster's name}
- Comment: {comment applied}

To retrieve mod comments of a user, the endpoint could take the following data as inputs:
- User: {user's name}
- Moderator: {mod's name (optional)}
- Broadcaster: {broadcaster's name}
- date: {date of comment (optional)}
- date range upper: {upper limit of date range (optional)}
- date range lower: {lower limit of date range (optional)}

On success, this would return the following for each comment:
- Success: {true}
- date: {date}
- User: {user's name}
- Moderator: {mod's name}
- Broadcaster: {broadcaster's name}
- Comment: {comment applied}

The addition of the Emote Library that is coming soon is a fantastic addition, this is great for solving the issue of disparity between partners and affiliates on emote variety, without undermining the parner program and is a fantastic compromise.

I would like to suggest the addition to the Twitch API to allow for enabling and disabling of active emotes from the Emote library via a privlaged API call from a token with sufficient privlages through oAUTH.

An example of the proposed usecase would be 4 API calls:
-Activate Emote [Params: Emote ID, (Optional: Emote Slot)]
-Deactivate Emote by ID [Params: Emote ID]
-Deactivate Emote by Slot [Params: Emote Slot]
-Replace Emote by ID [Params: Emote ID to Find in active emotes, Emote ID to replace with if Param 1 ID is found in active emotes]

• Activate Emote would add an emote from the emote library by specified ID to the first free slot on the channel's active emotes, or if specified would overwrite an emote in the specified slot.

• Deactivate Emote by ID would remove an emote from the active emotes by specified ID if present in any current slot, if emote ID not found, would do nothing or respond with an Error code.

• Deactivate Emote by Slot would deactivate any active emote found in a specified active emote slot, If slot is already clear, would do nothing or respond with an Error code.

• Replace by Emote ID would search active emotes in slots for a specified emote ID, if found the slot containing the found result would be cleared and then a emote from the emote library specified by ID would be activated to the specified slot.

Programatic access to these functions would allow for great viewer interaction by the creation of immersive experiences allowing viewers to use channel points or other events monitored for via IRC or the pubsub API, to trigger changes to active emotes without disrupting the viewing experience by requiring human intervention by the streamer or another user with privlages to swap emotes.
This would also facilitate the ability for channels that play a few different games or perhaps playthroughs such as variety streams to increase their appeal by creating emotes that are themed around current games or ongoing themed streams, which can then be automatically swapped in and out via the twitch API.

This is an amazing addition you've come up with here for the emote library and I would love to see this included programatically in the API for Follower Emotes, Subscriber Emotes and Bit Emotes ideally, but at the very least, subscriber emotes.

A topic to account for emotes being added or remove from "global" or a specific ChannelID would be useful.

It's hamstrung by

https://twitch.uservoice.com/forums/310213-developers/suggestions/39547780-emotes-by-channelid

As we can't catch up

There are a number of Twitch Extensions that would be good to know if/when emotes change. (HypeMeter for example)

And Developers of single channel bots will need to know so they can add/remove emotes from any channel commands.

It's also useful for custom channel tooling to keep lists up to date in custom tooling if/when https://twitch.uservoice.com/forums/310213-developers/suggestions/41137957-upload-emotes is actioned as well

This includes but is not limited to

• regular subscriber emotes
• bits/cheer emotes
• the channel sub badges
• the channel bits badges
• any other channel specific imagery that may be utilised in chat

The IRC gateway passes whispers using the WHISPER code:

[16:36:15] [@] @badges=bits-charity/1;color=#3E2E18;display-name=foo;emotes=;message-id=2;thread-id=21001676_470220570;turbo=0;user-id=2109996;user-type= :foo!foo!foo.twitch.tv WHISPER myuser :this is a whisper

But I am unable to find any reference to that code on https://dev.twitch.tv/docs/irc/commands where I would expect it, or any other documentation page under the "Chatbots and IRC" section.

I would suggest adding the WHISPER command to the list of commands at the top of the page on the IRC: Commands section, something similar to:

WHISPER Receive a Whisper message from another user


and then the prototype at the bottom, to include the fact that it appears the WHISPER command is (appears to be) a one-way command (the server can send a WHISPER to you, but you can't send a WHISPER to other users. (When I tried to send a whisper, I got: [16:45:58] tmi.twitch.tv reported an error: WHISPER :Unknown command).

Or maybe this is deprecated or not final yet, but I figured I'd point it out just in case it was an oversight. Thanks for all the hard work!

When viewers cheer, they use cheermotes and commonly emotes in their cheer messages. Unfortunately, the payload received from EventSub's channel.cheer callbacks only have the raw text as entered by the user, with no indiciation of which portions of that text are cheermotes nor emotes. Thus, I propose the following update to the callback payload, similar to the channel.subscription.message event, that passes along the data for both so that a consumer of EventSub can reconstruct the message:

{
    "subscription": {
        ...
    },
    "event": {
        ...
        "message": {
            "text": "Rah Rah Cheer! cheerwhal1 Cheer100 notACheer101 finite6ThrowBall",
            "cheermotes": [
                {
                    "begin": 16,
                    "end": 26,
                    "prefix": "cheerwhal"
                    "id": "1"
                },
                {
                    "begin": 27,
                    "end": 34,
                    "prefix": "Cheer"
                    "id": "100"
                }
            ],
            "emotes": [
                {
                    "begin": 48,
                    "end": 64,
                    "id": "emotesv2_4133039724974aa59589549eae677d03"
                }
            ]
        },
        ...
    }
}