PubSub Channel Points Data Layout Cleanup
Right now, most of the PubSub topics are inconsistent with each other (understandably so). This, however, is focusing on cleaning up some of the ChannelPoints event data that is either unnecessary, redundant, or unclear:
As a note, the information stripped away from the structure is not invalid data, but rather data we likely don't need per message and instead should have a fetch api like manner. One example is the image objects that are likely to never change in the lifetime of a reward. This would save needless encoding as well as any data costs there may be on either side. When discussing ~512 bytes, some people will assume that is not a lot, but when scaling that up to something that people have no monetary requirement to activate, then we are talking about data sizes several magnitudes larger across the site.
Example of new structure concept:
Cleaned up structure:
{
"Time": string,
"Id": GUID,
"Channel": User (see below),
"Reclaimer": User,
"UserInput": string,
"Status": string, -- ONLY If we can receive things other than "FULFILLED"
"Reward":{
"Id": GUID
"Name": string
"Prompt": string
"Cost": int,
"MaxLimit": int, -- 0 if no limit is present.
"CurrentCount": int
}
}
User Structure:
{
"User": {
"DisplayName": string
"UserName": string
"Id": GUID (currently an int encoded as a string)
},
}
Soaryn
shared this idea
-
Soaryn
commented
Marenthyu pointed out some changes as well as answered some questions on use cases for some of the fields.
==Redemption Info:==
Time String
Id GUID (String)
Channel User
Redeemer User
UserInput String
Status String
Reward RewardInfo==Fields of Reward:==
Id GUID (String)
Name String
Prompt String
Cost Integer
InputRequired Boolean
SubOnly Boolean
TotalUsed Integer
MaxLimit Integer -
Soaryn
commented
Old Data:
"type" - Unnecessary. This is encoded into the topic already one layer up. If you want this can be changed to context.
"data": - No reason to encapsulate further
"timestamp": - should just be named "time" to be consistent with other topics
"redemption": - Unnecessary encapsulation
"id": - should be on root.
"user": - Fine actually.
"channel_id": - Should match the user structure so you are presented with username and displayname as well.
"redeemed_at": - Should just be time. I understand there is a difference when the message was created and when a reward was redeemed. But we shouldn't need to know message creation
"reward": {
"id": - This is fine to have separate from "root/id"
"channel_id": - Unnecessary. We already have the channel this is associated to.
"title": - Fine
"prompt": - Fine
"cost": - Fine
"is_user_input_required": - Will we get an event at all before they input? "input_required" would be a better name
"is_sub_only": - Can remain
"max_per_stream": { "is_enabled": false, "max_per_stream": 0 } - perhaps too verbose,
"user_input": "yeooo",
}
Unnecessary Data static data. Provide an API fetch instead.:
"image" - Example on document has 147 byte per url for just image.
"default_image"
"background_color" - Why?
How do we even get the event if they are toggled?
"is_enabled": true,
"is_paused": false,
"is_in_stock": true,
"should_redemptions_skip_request_queue": - what?
"status": - Does this have other options?