Due to Twitch API restrictions, unauthenticated first-party chat includes certain information that is not displayed in Chatterino.

This information includes:

• Channel points redemptions (post-pubsub shutdown in April)
• Polls
• Predictions
• Outbound raids
• Outbound shoutouts
• Charity goals
• Follower/subscriber goals (though I personally don't care about adding this one)

Given that many broadcasters already authorize with Chatterino's client id, we can subscribe to this (effectively public) data and publish it to Chatterino clients via websocket.

With EventSub (via Conduit or Webhook), we don't need to hold onto user access tokens; we can simply create EventSub subscriptions using an app access token associated with the g5zg0400k4vhrx2g6xi4hgveruamlv client ID.

We would simply add a couple more scopes to the client login page so that we can create the various EventSub subscriptions we care about.

Since we're only forwarding EventSub payloads for events that are effectively public, an opt-out mechanism doesn't seem necessary, but this point could be debated further.

Chatterino clients should open a websocket to the relevant endpoint and specify the channel IDs they care about (i.e., have splits open). This JOIN payload can be sent multiple times as the user adds more channel splits.

{"type": "JOIN", "data": ["123", "456", "789"]}

If the user closes a channel split, the client should inform our server that further notifications related to the given channel ID are no longer requested.

{"type": "PART", "data": ["456"]}

In most cases we can simply forward the EventSub event payload as-is, but we can redact certain fields as needed.

• channel.shoutout.create: we can remove moderator_user_id, moderator_user_name, moderator_user_login (technically PubSub doesn't redact this information, but we can be better)

Use user.authorization.grant to trigger EventSub subscription creations.

Store authorized channel IDs to a SQL database (useful in case we want to add a new subscription type that doesn't require a new scope).

Upon receiving a JOIN request for a channel ID not in the SQL database, we could try to create an EventSub subscription to test whether the channel already authorized to our client ID (but before we started tracking user.authorization.grant). If they have authorized, we update the SQL db. If they haven't, we can have a in-memory cache or another SQL table for not-yet-authorized channels.

PubSub system: TODO

• Server costs
• Scaling headaches
• Can't switch to device code flow (unless we get streamers to separately authorize to our client ID)