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.

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"
                }
            ]
        },
        ...
    }
}

Extend the Videos API via a "metadata" endpoint, that provides additional data about the video.

Including but not limited to

• Category changes during the video
• Offsets are relative to the source video that the video is from. So for a highlight it would report the video it was cut from and include where in the origin file the highlight is cut from.

For Example: https://api.twitch.tv/helix/videos/metadata?id=1234
Metadata would support up to 100 (or 50) id's at once like Get Videos

Returns examples

A video of type archive
{
"data": [
{
"id": "1234",
"duration": 18000,
"chapters": [
{
"offset": 0,
"gameid": "200"
},
{
"offset": 500,
"gameid": "220"
}
],
parent: null
}
]
}

A video of type highlight
{
"data": [
{
"id": "1235",
"duration": 600,
"chapters": [
{
"offset": 300,
"game_id": "200"
}
],
"parent": {
"offset": 200,
"id": 4321
}
}
]
}

Use cases:

• if we present a highlight on a third party website, when the video is complete, we can present a easy way to go to the next Highlight in the series (where highlights are cut sequentially) or easily link to the original stream archive for continued watching.

This is an expansion of https://twitch.uservoice.com/forums/310213-developers/suggestions/38155990-return-tags-and-game-id-in-get-videos-in-helix

Brief description

https://dev.twitch.tv/docs/authentication/getting-tokens-oauth

When you get a token, it returns token_type as bearer

If you take this value as is and call helix endpoints it doesn't work as helix only accepts Bearer

How to reproduce

Generate a token
Construct a header using the returned data by concatenating elements from the returned JSON
`Authorization: ' . tokentype . ' ' . accesstoken

Call a helix endpoint
Get a 401
Expected behavior

Twitch accepts Bearer and bearer as valid

or

returns Bearer as the token type when fetching a token.

Additional context or questions

I'm not sure what the correct solutions is after a brief perusal of the RFC's

Request origin:

https://github.com/twitchdev/issues/issues/219

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!

Premise: stream.online encodes an id of the stream. stream.offline does not have such an id. Being able to pair this specific id with an online and offline state would be beneficial.

Objective: Add the matching id to stream.offline that pairs with stream.online

Notes: While it could be argued that a single broadcaster can only be live with a single id, it is still data oriented wise, more beneficial to have a symmetrical up and down payload, allowing quick queries on a state of a stream. Imagine a scenario where an online and offline event fire roughly at the same time. This creates a race condition that should not happen, but in theory still could at the current state.