In several discussions across Twitch-related Discord servers, it has been highlighted that the channel.chat.message payload currently lacks specific chatter status fields, such as ismoderator or isvip. Given the already substantial size of the payload, adding individual key-field pairs for each potential status could unnecessarily increase both bandwidth usage and processing time.

To address this, I propose the introduction of a single key: chatter_flags. This field would utilize a bit flag to represent multiple statuses within a single integer value. This approach not only minimizes data transmission but also simplifies the process of updating and checking user statuses—especially as new ntatuses are introduced. Checking badges is also not reliable due to them having the option to be hidden.

From the perspective of library maintainers, this solution would significantly streamline integration. Most libraries serve primarily as wrappers, with notable exceptions, and often recommend fetching moderator, follower, and VIP statuses through the HELIX API. They then suggest maintaining these details via EventSub, which isn't always practical for end users who want simple safeguards. The proposed chatter_flags would provide a more efficient and manageable method for handling user statuses directly through the message payload.

This change would be particularly beneficial for developers by reducing the complexity and overhead associated with managing multiple API calls and data synchronization, thereby allowing for more focused and efficient application development.

Example implementation:

Follower: 1st bit (1 << 0) = 1
VIP: 2nd bit (1 << 1) = 2
Moderator: 3rd bit (1 << 2) = 4
Subscriber: 4th bit (1 << 3) = 8
Turbo: 5th bit (1 << 4) = 16

User is only a Moderator: chatterflags = 4
Combined Moderator and Subscriber flags: chatterflags = 4 + 8 = 12
Combined Follower, Moderator and Subscriber flags = 1 + 4 + 8 = 13
Combined Follower and VIP flags: chatterflags = 1 + 2 = 3
Combined Subscriber and VIP flags: chatterflags = 8 + 2 = 10

Developers can then simply check the bits of the int to get and instant understanding of the chatter's status to perform or prevent actions. This could even be a V2 endpoint in parallel if people do not wish to receive the information.