feat: change duplicate message sending to use more variants #6088
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
3r01
force-pushed
the
duplicate-msg-variants
branch
from
a1d0493 to
b7f605f
Compare
|
warnings and formatting should now have been fixed |
|
This is quite complex. Could we make this simpler? For example, counting in binary (LSB first): I don't know if two spaces in multiple locations count as different for Twitch. If they don't, we could still do something similar to the space-only permutation, except that we also have one with the suffix. |
|
They do. See logs for 117691339 in #pajlada at 2025-03-17 00:20 UTC.
W dniu 16.03.2025 o 23:15, nerix pisze:
…
I don't know if two spaces in multiple locations count as different for Twitch.
|
They do.
Yes, if we accept that we will only ever use a maximum of one magic character (which pajlada had requested anyway), then I can remove the nesting logic. I would prefer to keep the logic for sorting by least edits to most edits (graded order). I think this is preferable because the unsorted bitmask will add multiple double-spaces before they are necessary, which might be an issue for longer messages which are close to the character limit(?). However, I think I can still simplify it with a stateful approach using Gosper's hack, which would remove the need for all of the combinatorial logic—that logic is for random access, which we do not need. So, I will make some changes. |
3r01
force-pushed
the
duplicate-msg-variants
branch
from
b7f605f to
2e4654d
Compare
|
As described above. Unfortunately, the ordering no longer strictly follows what was written in the OP. We now iterate over a single bitmask in graded order using Gosper's hack, up to a maximum of The bitmask has two sections:
The cycle restarts from the original message when either Outputs |
3r01
force-pushed
the
duplicate-msg-variants
branch
from
2e4654d to
d3f8168
Compare
|
changed magic char to |
3 participants
Implements permutation generation for duplicate messages.
In fast-moving chats, messages are often dropped. Since we currently generate only two message variations, we can easily trigger this error if any of our messages are dropped:
Your message was not sent because it is identical to the previous one you sent, less than 30 seconds ago.Since we can't reliably detect if a message was delivered, we can instead increase the number of permutations to reduce the rate of identical messages delivered in sequence, even if some are dropped.
For a message with N usable spaces and using M magic characters, the total permutations are 2^(N + M).
The amount of permutations that we actually generate and use can be controlled by the constants
TARGET_PERMUTATION_COUNTandMAX_MAGIC_CHARACTERSinTwitchChannel.cpp.We generate the minimum number of variants needed to reach the target permutation count, in the following order:
TwitchChannel.cpp.TARGET_PERMUTATION_COUNT, ORMAX_MAGIC_CHARACTERS, whichever is reached first.In these examples, the target permutation count is 4, and the max magic characters is 1.
The magic character is represented by ?
When messages are dropped, the chance of landing on a duplicate when delivery resumes is
1 / TARGET_PERMUTATION_COUNT, assuming that there are enough spaces available to reach the target permutation count. (This represents the worst case -- however, in practise the chance is lower than this unless you are spamming very fast during a period where delivery is failing).The existing implementation has 2 permutations, so a 50% chance of landing on a duplicate.
This can inform how to tune
TARGET_PERMUTATION_COUNTandMAX_MAGIC_CHARACTERS.In this PR,
MAX_MAGIC_CHARACTERS = 1to limit obstructive variants, andTARGET_PERMUTATION_COUNT = 4as a conservative value—halving the denial rate compared to the existing implementation in the very worst case. However, a higherTARGET_PERMUTATION_COUNTwould be fine, sinceMAX_MAGIC_CHARACTERSalready prevents obstructive variants. I leave this decision to existing maintainers.Duplicate of #6082 with improvements - I was being lazy and not creating an account, so @apa420 submitted for me.
Thank you @apa420 - #6082 can be closed.