More usable format for moderation.screened.subs messages.

[zephyyrr]

Would it be possible to include a parsed version of the message->tags->system-msg field?
I want to do stuff like count twitch prime subs but have to now write string parsing logic in SQL (possible, but not exactly my favourite pasttime). The messages are also a bit too nested. Three layers for two values? A bit over the top in my opinion.

I would like to see something like

{
  "$meta": {
     ...
  },
  "id": { 
    "$type": "string", //Maybe GUID? Not sure what Twitch use for their user ids. 
      "$required": true, 
      "$description": "The id number of the user." 
   },
  "type": { 
    "$type": "enum", 
      "$required": true, 
      "$description": "The type of subscription",
      "$values": ["Prime", "Tier 1", "Tier 2", "Tier 3"] 
   },
  "name": { 
    "$type": "string", 
      "$required": true, 
      "$description": "The name of the twitch user that subscribed" 
   },
  "trailing":  { 
    "$type": "string", 
    "$required": false, 
    "$description": "The message following the system message." 
  },
  "length": { 
    "$type": "int", 
      "$required": true, 
      "$description": "The number of months in a row the user subscribed" 
   },
  "trailing":  { 
    "$type": "string",
     "$required": false, 
     "$description": "The message following the system message." 
  },
  "system-msg": { 
    "$type": "string", 
      "$required": true, 
      "$description": "The system message supplied by Twitch." 
    }
}

Or similar.

[opl-]

This is quite an old issue, but I might as well answer it.

The new schema includes some examples of what the field might contain, but some might be and probably still are missing, because Twitch is Twitch and consistency is not their priority.

The reason the property is so deeply nested is because the entire object is just the Twitch IRC message, deserialized into an object, which I think should be a reasonable thing to do in this context.

Best I can suggest is to check the rabbit explorer view in Grafana that I made recently, which should make it easier to figure out what the system-msg values might be.

Oh, and as for the type of the type of Twitch user IDs, it used to be strings in the old API (i.e. the usernames) and an integer sent as a string since v5 (including the new "new" API).

[zephyyrr]

Yes, but when I wrote the issue, it was not just the deserialized Twitch message, it was a subset of the message (two values) with the exact same structure, which is what I was opposed to. If there was care taken to process the message to remove anything else, it would make a lot more sense to also restructure it be more suitable for further processing. The point of the message is not just to pass on whatever Twitch say, but to turn it into something useful for downstream, so we don't have to know everything about the Twitch APIs in all applications.

[zoton2]

I don't know if it was changed much since you made the issue, but yes it could do with some cleaning up, which is probably best done when we actually integrate the RabbitMQ stuff into the mods tool where these messages actually come from.