PubSub Inconsistencies

[soaryn]

Both of these examples were pulled straight from the documentation.

Bits Example

{
   "type": "MESSAGE",
   "data": {
      "topic": "channel-bits-events-v1.44322889",
      "message": "{\"data\":{\"user_name\":\"dallasnchains\",\"channel_name\":\"dallas\",\"user_id\":\"129454141\",\"channel_id\":\"44322889\",\"time\":\"2017-02-09T13:23:58.168Z\",\"chat_message\":\"cheer10000 New badge hype!\",\"bits_used\":10000,\"total_bits_used\":25000,\"context\":\"cheer\",\"badge_entitlement\":{\"new_version\":25000,\"previous_version\":10000}},\"version\":\"1.0\",\"message_type\":\"bits_event\",\"message_id\":\"8145728a4-35f0-4cf7-9dc0-f2ef24de1eb6\"}"
   }
}

Subs Example

{
   "type": "MESSAGE",
   "data": {
      "topic": "channel-subscribe-events-v1.44322889",
      "message": {
         "user_name": "dallas",
         "display_name": "dallas", 
         "channel_name": "twitch",
         "user_id": "44322889",
         "channel_id": "12826",
         "time": "2015-12-19T16:39:57-08:00",
         "sub_plan": "Prime"/"1000"/"2000"/"3000",
         "sub_plan_name": "Mr_Woodchuck - Channel Subscription (mr_woodchuck)",
         "months": 9,
         "context": "sub"/"resub",
         "sub_message": {
            "message": "A Twitch baby is born! KappaHD",
            "emotes": [
            {
               "start": 23,
               "end": 7,
               "id": 2867
            }]
         }
     }
   }
}

The key Inconsistencies:

• Bits follow the chain data.message.data while subs and commerce follow data.message. The bits data seemingly have an unnecessary extra layer
• Subs and commerce both have an emotes location struct, that is lacking in cheers. With the number of cheermote variants, this ‘emote’ struct is rather vital for parsing cheer messages
• Subs and Commerce have display name while cheers only utilize an user_name. Having this data point live would be useful for when using it for a notifier as it will print out the way the user desired, rather than having to resort to all Upper or lower case.

[3ventic]

They should be in the same overall format. The subs example documents

The data and message fields are JSON strings and will need to be escaped.

[Muddr]

It is kind of annoying that for Bits the data.message is Stringify’d and Subscription/Commerce are a regular object.
I’m guessing at this point it won’t be changed until a new PubSub version due to the breakage it’d cause.

[soaryn]

The problem isn’t so much the escaped message, but rather the contents of said messages.

Bit messages resolve to:
blob: { data: { Message Data }}

Where as EVERYTHING else resolve to
blob: { Message Data }

These resolutions are AFTER the message has been escaped. As a case scenario, if I were to request the sub data I would simply call something similar to stored_SubData.user_name or stored_SubData[“user_name”].

Bits on the other hand required stored_BitsData.data.user_name

[3ventic]

There’s also metadata attached to bits messages, the blob you get back looks roughly like this:

Note the message_id, message_type and version fields outside the actual data. Subscription and commerce messages have nothing like it, so I doubt adding a layer to it for consistency’s sake is worth the breaking change.

[3ventic]

@Muddr

It is kind of annoying that for Bits the data.message is Stringify’d and Subscription/Commerce are a regular object.

I’m guessing at this point it won’t be changed until a new PubSub version due to the breakage it’d cause.

All the $.data.messages should be stringified, based on the documentation. Are they not in reality?

[soaryn]

@3ventic

All the $.data.messages should be stringified, based on the documentation. Are they not in reality?

They are

That part of the documentation is just strange.

@3ventic

Note the message_id, message_type and version fields outside the actual data. Subscription and commerce messages have nothing like it, so I doubt adding a layer to it for consistency’s sake is worth the breaking change.

Message_id is the only true field that makes sense to keep really and I am not even sure how useful it truly is, as the parent object tells you the same info as the type (topic) and the version since it is the version you subscribed to (v1)

Those fields feel like they were revised when building subs and commerce, but no changes have been propagated back to Bits.