I’m looking forward to this proposal being implemented, as I feel it would solve a lot of issues that are holding me back from diving into developing the extension I have been envisioning. I have one point of clarification and one suggestion:
Clarification: The Websub entitlement consumption topic, extension_consumption_request, is supposed to be sent in response to a request to consume an entitlement i.e. consumeEntitlement(id, quantity), correct? If that’s the case, shouldn’t it have a benefit_id attached to it rather than a product? As the example is currently displayed, it doesn’t make sense to me, unless I’m missing something.
Suggestion: It would greatly simplify my potential extensions if an additional user-defined string or very small JSON blob, possibly named userDefinedPayload or details or anything along those lines, could be included in the method to consumeEntitlement or the backend equivalent. This user-defined value would be sent unmodified along in the Websub consumption topic’s data object of the payload.
To explain the use case, in your second example of a voting overlay, when the user has decided how they want to vote, the Extension front-end code could directly call consumeEntitlement with a user-defined value of the item they are voting for. The backend, subscribed to the Websub topic, would get a notification of the vote, record it based on the user-defined value included in the data object, and confirm the consumption.
The advantages of this approach over the approach described above include reducing the number of calls to the Twitch API needed to be made and waited on by the backend service, as well as eliminating the need for the front-end code to communicate directly to the EBS. Then, if this is a simple extension, by having the valid items to be voted on distributed by the Configuration Service, viewer’s front-end code would never need to directly interact with the EBS at all, only with Twitch APIs. This would both simplify the code as well as reduce backend costs to the developer.
Hoping to see this RFC rolled out soon!