Qs for new community mystery gifting and a suggestion

I have some questions and perhaps some suggestions to make it easier to parse this new feature.

I know that the IRC sends out an initial message about the community sub gift with the flags
msg-id=submysterygift;msg-param-mass-gift-count=XX;msg-param-sender-count=XX

but what I’m curious about is the order of the individual subscription gift messages following after that.

  • Are they all queued up in order?
    – What if the same person does another community gift?
    – What if the same person does a normal sub gift after the community gift?
    – What if another person does a normal/gift/community gift?
  • What if the service has a hiccup sending out all individual messages?

I am asking this because I want to detect this mass community gifting and then ignore the ‘individual’ sub gift messages as that is something not needed. I can ignore the following x gift messages from the same gifter determined by the msg-param-mass-gift-count but what if the individual messages are not queued up in order as described above? What if the service gets interrupted, I could potentially add a timeout to stop ignoring, but could potentially cause issues if the service starts outputting again.

– suggestion –

I would say to not output the individual messages after a community mystery gift but some applications want to track who received a subscription from that person for statistic tracking, so maybe add a special flag to the normal gift sub message indicating if the gifted sub was a mystery sub or not (true or false) this way programs or services (like Alerts) only caring for the mass community mystery gift can ignore all following USERNOTICE messages that have set the mystery gift flag to true.

3 Likes

I don’t want to unnecessary bump this thread but has anyone else worked on this parsing the community gift while ignoring the bulk of other gift messages from the community gift only? Or maybe has a better idea how to handle this, to only extract the community gift message, ignore the bulk that comes with it, while still catching individual gifts and subs via Twitch IRC.

I think with the suggestion of an additional flag, it would make it allot easier to ignore these.

I’m in the same boat, and also would like the individual gift alerts to have an additional flag which indicates that they came from a community mystery gift, so that I could ignore them.

1 Like

Hey Everyone,

For reference I’m the Product Manager for Subscriptions at Twitch and helped develop this specific feature. I can answer some of your questions.

Q1. Are they all queued up in order?
A1. They are not queued up. The implementation kicks of the number of gifts into separate state machines that manage our eligibility and entitlements. Because we have fallbacks and retries on eligibility with varying timeframes it’s hard to guarantee a queue. We are exploring ways to do that to enhance the experience in the future.

Q2. What if the same person does another community gift?
A2. As per Q1, we would initiate another set of child state machines to manage the sub gifts. So they would potentially intermingle the chat messages of the original community gift.

Q3. What if the same person does a normal sub gift after the community gift?
A3. Same a Q2.

Q4. What if another person does a normal/gift/community gift?
A4. The overall behavior is the same. They essentially happen when they happen. We currently do not queue the subscription messages.

Q5. What if the service has a hiccup sending out all individual messages?
A5. We will continue to retry with various lengths depending on what the failure state is. In rare circumstances (service failures), the retries could time out and not all related chat messages would be sent or shown

In reading your suggestion, we can definitely explore adding a special flag to the individual notifications that are related to a community gift. We may have some other types of notifications coming down the road related to gifts so it would be valuable to allow you to distinguish them.

Please feel free to reach out if you have additional questions or suggestions.

Thank you for answering these questions, so it is atm hard to properly prase the mystery gifts only as it just happens when they happen when other events get in-between.

Would be awesome to have a flag, now that i think about it msg-id could be (re)used with the type of mysterygift so the msg-id of USERNOTICE is exanded to sub, resub, subgift , raid , ritual and mysterygift and would solve most of the concerns and issues to properly parse and ignore these mystery gifts while still detecting normal (re)subs and gifts.

I think changing from subgift to mysterygift wouldn’t be ideal, as that’d mean it’s a potentially breaking change with some gifts now falling through the cracks for apps not designed to listen for a mysterygift.

What may be a interesting way to do it could be to have the mysterygift message contain an id, which all subgifts can refer to, that way if there’s no reference then it’s a 1 off subgift, otherwise not only would the presence of a reference indicate it’s one of multiple mass gifts but you could even see which one spawned it in the case of multiple from the same user being done within a short space of time. I’m usually opposed to additional tags being added, but this would prevent it being a breaking change and gifts being missed, and add additional data that’s currently missing.

1 Like

Just need a id/reference to group them together. Nothing more nothing less

If only someone came up with a way to group messages in IRC 4 years ago: https://ircv3.net/specs/extensions/batch-3.2.html

The problem is that with the current setup, you can’t reliably do notifications for both individual sub gifts and Community sub gifts with separate behaviors. You have to pick one or the other, and if someone gifts a non-trivial number of subs, the notification would be out of control.

That’s why the flag is so useful, and we’d like to see it added.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.