[Feature Request] EventSub triggers through template files

[Xemdo]

Background

Currently EventSub subscription are hard-coded into the program. This leads to a large code changes and a new release being required every time a new EventSub subscription is created, or when a Beta subscription is modified.

Because of the nature of code modifications and releases, this leads to new EventSub subscriptions support in the CLI CLI being released often at a minimum of 2 weeks after the release on Twitch's production EventSub.

Proposal

I propose moving to a system where subscription template files are used, stored within the application config folder, and pulled from Github.

Folder structure

EventSub subscription files would be stored within the folder given by GetApplicationDir(), which gives a folder such as ~/.config/twitch-cli/. Inside of there, a folder would be created called eventsub.

Subscription file

Subscription files would be pseudo-json files, requiring the JSON file extension but having some flexibility away from the normal JSON formats.
The file would contain the JSON for the EventSub, with some additional templates under the handlebars format ({{variable}}). Known templates would have to be hard-coded to have default programmatic values. For example {{timestamp}} would get the current RFC3339Nano timestamp, and {{subscription-id}} would be the automatically generated Subscription ID. An override for these would be possible, and is described further down.

An example of this file would be as such (channel.shield_mode.begin)

{
  "subscription": {
    "id": "{{subscription-id}}",
    "status": "{{subscription-status}}",
    "type": "channel.shield_mode.begin",
    "version": "beta",
    "condition": {
      "broadcaster_user_id": "{{broadcaster-user-id}}",
      "moderator_user_id": "{{moderator-user-id}}"
    },
    "transport": {
      "method": "webhook",
      "callback": "null"
    },
    "created_at": "{{timestamp}}",
    "cost": 0
  },
  "event": {
    "broadcaster_user_id": "{{broadcaster-user-id}}",
    "broadcaster_user_name": "{{broadcaster-user-name}}",
    "broadcaster_user_login": "{{broadcaster-user-login}}",
    "moderator_user_id": "{{moderator-user-id}}",
    "moderator_user_name": "{{moderator-user-name}}",
    "moderator_user_login": "{{moderator-user-login}}",
    "started_at": "{{timestamp-10m}}"
  }
}

Timestamp template

The timestamp template would be {{timestamp}}, which will return the current time in RFC3339Nano.
However, in some cases time will need to be modified. With timestamp there needs to be the ability to add and subtract time. This would be accomplished by adding - and + along with a timeframe to the timestamp. Support would be needed for decimal values, such as 0.5, as well as whole integers such as 5.

Timeframes would be in the format of <number><time type>, such as 1.5h for 1.5 hours or 275s for 275 seconds.
An example of this in the file can be seen above, with the started_at field.

Random times are also necessary, so this can be performed by adding - or + r(<number>:<number><time type>), with the first number being the lower bound, the second number being the higher bound, and the time type being the same as the normal timeframe format.
An example of this, to choose a random time between 30 and 120 minutes, would look like:

"ends_at": "{{timestamp+r(30:120m)}}"

Template override

Templates provide data that is programmatically generated, but when replicating specific events users will need to be able to use their own data instead.
This would be achieved by two ways:

• A direct override, which allows users to override a template value that may appear multiple times within the file
• Overriding specific fields via user-provided JSON
  In regards to the second overriding means, it would look like something like this:

twitch event trigger channel.shield_mode.begin --override '{"subscription":{"transport":{"callback":"https://example.com"}}}'

The above example would override the callback field and nothing else.

Distributing the template files

TBD...
Basic idea: Templates can be in a separate branch, built into a latest.zip or latest.tar.gz file when build/deploy is ran, and provided via Github Pages alongside a version.txt file that tells the latest EventSub zip/tar build date