Alternative-Client voice chat patch

Hey discord employee's, I'm very sure you are all quite aware of the problem with alternative discord clients and re-using old discord clients, so I have a solution for the voice chat end that wont effect performance at all. End-to-end encryption by performing an Xor operation on the Encoded Opus Data before its sent with the packet, as the Issue has Increased with people constantly using alternative clients (such as Ripcord, Abaddon or Lightcord). Their main attraction is Voice Chat. The very simple fix to these clients ability to voice chat is to use unique end-to-end encryption that isolates the opus build made for discord to only discord. Now you might be saying “Ok but we can just add a single byte to the end of the sent packet to check if its ours.”, and to this I say that you're a simple wire-shark operation away from having all clients having Voice Chat again, I recommend you do however add a qword to the very end of the sent packet's data with a unique value to check if its a legitimate packet (unique value), The way the end-to-end encryption would work would be something like this.

constexpr uint32_t AutogeneratedKey = (__TIME__[7] >> 2) * __TIME__[6];
uint32_t XorArray(unsigned char* array, uint32_t Size = 480, uint32_t Key = AutogeneratedKey)
{
    for (uint32_t i = 0; i < Size; i++) array[i] = (array[i] ^ Key);
    return Key;
}

void DexorArray(unsigned char* array, uint32_t Size = 480, uint32_t Key = AutogeneratedKey)
{
    for (uint32_t i = 0; i < Size; i++) array[i] = (array[i] ^ Key);
}
Here we have some basic C functions that perform an Xor operation on an array of bytes by an Xor Key (example is compile time based). For discord you can do one of 2 things, send the Xor Key with the packet which would increase the packet size by 4 more bytes or have a constant Xor Key that changes every update (probably the most reliable since everything is handled client side for discord Voice Chat so I'll be showcasing this method).
Here's a good depiction of how this would look implemented,

as you can see here, the data is Xor protected after it has been encoded, once that has been done, the packet is sent to the voice server. Now this might look unreliable like “Well how does the other client know the Xor Key?” and take a closer look, Voice Chat is client based, meaning, the Xor key can be applied to the decoder at compile time as well.

As you can see in this screenshot, the decoder is using the same key as the encoder from compile time, to validate the packet before it actually makes it to the opus decoder, send an extra 8 bytes of data with the packet at the end to check if the packet is valid (unique identifier), while yes this would be futile against web traffic loggers, it would act as a barrier for invalid data even making it to the decoder. In conclusion the point is to simply add Xor encryption to the opus audio data and add a unique identifier to the end of the audio packets to validate their version (up-to-date). Doing all of this would put an end to all simple alternative discord clients and use of older discord client's (such as Lightcord) or using older voice modules.

The reason it would put an end to “Simple” Alternative Clients Voice Chat is because it would require Reverse Engineering to obtain the current Xor Key to enable the ability to Voice Chat every single update. But why do this? Since it's against the Terms of Service I would assume you would want something quick and easy to make it harder to violate the Terms, and who knows, maybe it'll make you more $$$.

(Edit) forgot to Include an older Image depiction I created of how this entire process would look (doesn't have the unique 8 byte identifier checking process because its older)