-
Notifications
You must be signed in to change notification settings - Fork 679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto claim Moments #428
Comments
Great idea! I'm really looking forward to the implementation. |
Hope this can be done, that would be awesome. |
+1, would be better to autoclaim twitch moments if possible, sometimes you tab out for a few seconds and you lose the ability to claim them |
So I'm extremely keen on implementing this myself, and have started digging into how Moments are received and claimed. I'm fairly certain that Moments come from the PubSub API by listening to the They are then later claimed through the GQL API using the following mutation: mutation CommunityMomentCallout_Claim($input: ClaimCommunityMomentInput!) {
claimCommunityMoment(input: $input) {
moment {
id
}
error
}
} Now I'm missing a few pieces here - (1) the schema for Any of the following will be really helpful in helping me implement this:
Or even better, if anyone here personally owns a channel with Moments - please reach out to me, I just need to capture the data for one generated Moment. |
For the PubSub topic I came to the same conclusion a month ago. It's probably the right direction. However I wasn't able to capture any packets. As this action is limited to a few per months, it's hard to predict when this happens. |
So I was really lucky yesterday and managed to capture the GQL request to redeem a Moment: [
{
"operationName": "CommunityMomentCallout_Claim",
"variables": {
"input": {
"momentID": $MOMENT_ID
}
},
"extensions": {
"persistedQuery": {
"version": 1,
"sha256Hash": "e2d67415aead910f7f9ceb45a77b750a1e1d9622c936d832328a0689e054db62"
}
}
}
] However, very unfortunately I wasn't able to capture in incoming package on the PubSub websocket - but digging through the frontend JavaScript I found the following: // ...
{
CommunityMomentStart: "active",
CommunityMomentClaim: "claimed",
}
// ...
if (l.type === E.qU.CommunityMomentStart) {
var c = {
momentID: l.data.moment_id,
type: N.S.CommunityMoment,
userID: null !== (i = null == t ? void 0 : t.id) && void 0 !== i ? i : null,
userLogin: null !== (a = null == t ? void 0 : t.login) && void 0 !== a ? a : null
} Using this I think it would be reasonable to deduce that an example response from the topic might be something like: {
"type": "MESSAGE",
"data": {
"topic": "community-moments-channel-v1.<channel_id>",
"message": "{\"type\":\"active\",\"moment_id\":<moment_id>}"
}
} @RakSrinaNa What do you think? |
I can't really say much, maybe, maybe not. But this seems to be similar to what twitch do with other endpoints. |
Though the format of the json payload from the GQL is probably different. I don't think there's a message field. You can see examples of other messages from twitch: https://github.com/RakSrinaNa/ChannelPointsMiner/tree/main/miner/src/test/resources/api/gql |
Yes, you're right. Just to clarify - the JSON payload snippet is what I'm expecting from the PubSub API when listening to the This is the response for the GQL [
{
"data": {
"claimCommunityMoment": {
"moment": {
"id": $MOMENT_ID,
"__typename": "CommunityMoment"
},
"error": null,
"__typename": "ClaimCommunityMomentPayload"
}
},
"extensions": {
"durationMilliseconds": 9,
"operationName": "CommunityMomentCallout_Claim",
"requestID": $REQUEST_ID
}
}
] |
My bad for the above link. What Twitch send us is through the WS (PubSub) not GQL. So it'd be more like the following I think: {
"type": "MESSAGE",
"data": {
"topic": "community-moments-channel-v1.<channel_id>",
"message": "{\"type\":\"active\",\"data\":{\"moment_id\":<moment_id>}}"
}
} However the |
The value of But yes agreed - I made an error, the Thanks for the help. I'll implement this in my own fork and revert the next time I get Moment (might be a while) :) |
Seems to be in features.chat.components.chat-command-handlers.component-8c9fbcdf482be806bb8a.js Other things to note from the JS:
e.INVALID_MOMENT_ID = "INVALID_MOMENT_ID",
e.CLAIM_PERIOD_EXPIRED = "CLAIM_PERIOD_EXPIRED",
e.ALREADY_CLAIMED = "ALREADY_CLAIMED",
e.INVALID_REQUEST = "INVALID_REQUEST", |
So mining for 15+ channels who frequently create Moments paid off. 😄 Here's the payload from the PubSub API when there's a moment active: {
"type": "active",
"data": {
"moment_id": "0ad4b5b8-be38-4245-b20d-af357aec18e9",
"channel_id": "215105998",
"clip_slug": "SparklySmokyFriesFloof-jwMEwyARRfqhEImG"
}
} (Moment link: https://clips.twitch.tv/SparklySmokyFriesFloof-jwMEwyARRfqhEImG) Everything else about claiming Moments is as we already knew it from the conversations above. |
What a man 👏 You've done quite a lot for this, respect. I'm curious, can you give a list of streamers that "frequently create Moments" so that it'll be easier to test implementations? |
Here were the list of streamers that I was testing this out with: Alternatively this Google search query will give you pretty good results as well. |
This addon collects moments automatically on open tabs, https://chrome.google.com/webstore/detail/automatic-twitch-drops-mo/kfhgpagdjjoieckminnmigmpeclkdmjm Can you see how they auto collect it and implement it in this python script? |
I would like to ask for an enhancement to auto-claim moments.
The text was updated successfully, but these errors were encountered: