Console AND mobile gamers have INCREDIBLY few options for overlays.

But we appreciate the 1-2 teams out there trying to make things work completely source agnostic... for example... Overlay Expert.

However there are games with Game Specific Overlays (BL3 which also supports console, Lost Ark, Card games with mobile OS versions...) that we cannot use at the Same Time.

Even if we just want to put in some nice alerts for thanks for following and etc.

EXAMPLE: Play Destiny 2 on Console/PC/Cloud with cross-save-etc? How about the D2 armory extension + an overlay extension for your followers?

Can't do it right now.

I'd gladly give up 1 of the my normal extension slots to do 2 overlay extensions. Let people pick?

I feel the new CSP fields in the console can be improved.

Right now it states:

Comma-separated list of base URLs from which your Extension can load images (e.g. <img> HTML elements and favicons). These values will be used by the HTTP Content-Security-Policy (CSP) img-src directive

Comma-separated list of base URLs from which your Extension can load additional media (i.e. <audio>, <video>, and <track> HTML elements). These values will be used by the HTTP Content-Security-Policy (CSP) media-src directive.

Comma-separated list of base URLs from which your Extension can load information via scripting interfaces (e.g. API calls, fetch(), XMLHttpRequest, WebSockets). These values will be used by the HTTP Content-Security-Policy (CSP) connect-src directive.

A correctly constructed CSP for a given policy entry doesn't contain commas.

I feel it would be more practical to accept a "standard" CSP into these fields.

So you would specify in the fields a "valid" CSP for connct/img/media source. as per MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Rather than a CSV that is beint intrepreted either by automation or the reviewer.

It would make sense all around that I enter, for image domains for example:

https://www.google-analytics.com/ https://images.igdb.com/ https://static-cdn.jtvnw.net/ https://pbs.twimg.com/

instead of

https://www.google-analytics.com/,https://images.igdb.com/,https://static-cdn.jtvnw.net/,https://pbs.twimg.com/

The latter is not a valid CSP, but the former is.

This makes it easier for developers to correctly specify a https and a wss for socket based operations. And means what is entered into the field is a direct match to what you would test with if you have as test server that provides the files and the CSP headers when in localtest.

Libraries such as helmet both accept a "valid" CSP or an array of entries. So in code:

app.use(twitchextensioncsp({
    clientID: 'ca2np9xlw9bx7vlppwn8ekwz9ws0io',
    enableMobile: true,
    imgSrc: [
        'https://www.google-analytics.com/ https://images.igdb.com/ https://static-cdn.jtvnw.net/ https://pbs.twimg.com/ https://twitch.extensions.barrycarlyon.co.uk/'
    ],

is valid as is

app.use(twitchextensioncsp({
    clientID: 'ca2np9xlw9bx7vlppwn8ekwz9ws0io',
    enableMobile: true,
    imgSrc: [
        'https://www.google-analytics.com/',
        'https://images.igdb.com/',
        'https://static-cdn.jtvnw.net/',
        'https://pbs.twimg.com/',
        'https://twitch.extensions.barrycarlyon.co.uk/'
    ],

The string version is easier to copy and paste from my test server to the entry field in the console. And the string version (without commas is a Valid CSP)

This means less complications by Twitch requiring a Comma Seperated List.

TLDR:

    imgSrc: [
        'https://www.google-analytics.com/ https://images.igdb.com/ https://static-cdn.jtvnw.net/ https://pbs.twimg.com/ https://twitch.extensions.barrycarlyon.co.uk/'
    ],

the above is valid CSP the below (if I direct copied from the console into code) is not.

    imgSrc: [
        'https://www.google-analytics.com/,https://images.igdb.com/,https://static-cdn.jtvnw.net/,https://pbs.twimg.com/,https://twitch.extensions.barrycarlyon.co.uk/'
    ],

So I propose change the CSP fields to accept valid CSP not a CSV.

Or it should be laid out like the oAuth redirect URI's (multiple text fields one URL per field add/remove buttons etc)

Extension Developers can provide their extension in whatever langauge they want.

But Send Extension chat doesn't support translations.

Please extend https://dev.twitch.tv/docs/api/reference#send-extension-chat-message to support translations

So instead of

{
  "text": "Hello",
  "extension_id": "uo6dggojyb8d6soh92zknwmi5ej1q2",
  "extension_version": "0.0.9"
}

as the payload

support

{
  "texts": {
"en": "words and stuff",
"de": "the german transation",
"fr": "the french translation"
   },
  "extension_id": "uo6dggojyb8d6soh92zknwmi5ej1q2",
  "extension_version": "0.0.9"
}

And then the Twitch frontend will select whatever language the user is using and default to broadcaster language if a matching language not found.

or support a "default"

{
  "texts": {
"default": "words and stuff",
"en": "words and stuff",
"de": "the german transation",
"fr": "the french translation"
   },
  "extension_id": "uo6dggojyb8d6soh92zknwmi5ej1q2",
  "extension_version": "0.0.9"
}

Naturally use/support the language codes that language uses in the query string parameters from https://dev.twitch.tv/docs/extensions/reference#client-query-parameters

Why is the share always 80% streamer and 20% developer? Would be way better if the developers could decide their extension percentage.

If I sell an cosmetic item in my game ( on my website) for 5$ I get like 4.8$
If I want to sell the same item on twitch I would need to sell it for 24$ to get 4.8$

So as developer I have these options:

• Don't use Bits -> Streamer receives 0$
• Link to our website -> Streamer receives 0$
• Make prices way to expensive -> nobody buys -> Streamer receives 0$

So if you make bits adjustable for every extension it would give us a lot more possibilities. Could be a slider from 10-90% or something like that so that is guaranteed that the streamer gets at least something.

This new system could also lead to more people creating extensions for twitch because of the better (changeable) share

As a developer that loves creating new ways of interacting with my viewers there are things that would benefit from using the extension system but that would be way too specific to my stream to be validated for everyone.

As far as i know, the only ways of having an extension enabled for my viewers is either to go through the validation process or whitelist every users one by one.

Maybe i'm mistaken, but I don't think twitch would validate an extension if other users cannot actually use it, and whitelisting the viewers one by one is not viable at all.

Is there a reason why it's impossible to have an extension i made avaiable for my viewers without those two options ?

I believe this would open up new creative interactions.