TASagent/TASagentTwitchBotCore

deprecation of WebSub handling

Closed this issue · 3 comments

So I suppose the end goal is to migrate from WebSub to EventSub. To start the discussion off I'll put down some of my thoughts. Keep in mind I'm trying to take the 'easiest' approach with minimal changes to get this working; but could build on.

We can create a facade layer that acts as an interface to EventSub. It could be a new project with x endpoints, where each endpoint represents a subscription to a topic in EventHub (possibly more to handle authorization logic). This facade layer creates a websocket connection to: TASagentTwitchBotDemos.

so effectively let's say there's a follow webhook in the facade layer:

in pseudocode:

FollowReceived_Webhook(payload):
    VerifyTwitchPayloadSignature();
    if TASagentTwitchBotDemos is connected through websocket and online:
        SendPayload();
    if TASagentTwitchBotDemos is no connected through websocket or offline:
      DoNothing();
  return HTTP_STATUS_CODE_200;

Let's say we want to extend it in the future, we can host a database and have it update a database with the data in addition to sending the payload and slowly migrate features to the skeleton api layer.

Now obviously there is an issue because we'd have to host this through some permanent ssl domain, however I think for that there are a few options; for cost and maintenence (or lack of) I like serverless. We can make a CloudFormation template to automatically setup the endpoints (however domain records may need to be done manually as well as the first issuance of a SSL certificate if we use AWS).

Yeah, the initial description is what I had in mind. To do anything more becomes a lot more complicated, since every app can have a different internal database. As a potential solution, at least for the near-term, I do own a server and the tas.wtf domain. I figure we could set up a registration procedure where the bot provides an alias and some credentials, etc.

Sure thing; if you have a persistent server + domain name you can get a ssl cert for that sounds ideal.

In the future:

The database problem won't be so bad, when it's necessary we can do a multi-tenant approach where data is segmented by row key. So essentially each table would get an additional column that gets filtered by (maybe an index) 'StreamerId', and one additional table could be made for 'Streamers' with StreamerId + other neccessary identity.

https://server.tas.wtf has recently been set up to handle eventsub.