WebCord blocks StreamKit overlay

[3e849f2e5c]

Aknowledgements

• I have checked that there's no other issue describing the same or
  similar problem that I currently have, regardless if it has been
  closed or open.

• I can confirm that this is not an issue with the Discord website,
  but it is a problem specific to the WebCord itself. I have tested
  if this bug occurs on Chromium/Chrome or any other Chromium-based
  browser that uses unpatched/upstream Chromium engine.

• I have tried running the build from the master branch and it does
  not have any fixes implemented according to my issue.

• My issue describes one of the unstable and/or not fully implemented
  features.

• I have found a workaround to mitigate or temporarily fix this issue
  in affected releases (please write it in Additional context section
  below).

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

20.0.0

Application version

v3.7.1

Bug description

While WebCord is running the StreamKit Overlay fails to connect. If both WebCord and the native Discord client are launched at the same time then the overlay fails to connect to the native client until WebCord has been closed.

Additional context

I personally have 2 Discord accounts, my main running in WebCord and my second account in the native Discord client and my secondary account I use for streaming and use the overlay kit with it but because of this bug I have to close WebCord while I'm streaming.

0001-0630.mp4

[SpacingBat3]

I have a feeling this is caused when StreamKit is looking for Discord client via WS and finds WebCord's WebSocket instead of the Discord's. As both Discord and WebCord should accuire one port from list of all, I believe ensuring that WebCord runs as the second client should fix/workaround your issue.

[SpacingBat3]

Also after WebCord is closed you should restart Discord as well to ensure it will catch the first available port from range.

[3e849f2e5c]

Ah yeah you are right, launching native Discord first does make it work. Never thought the order would affect it

Native discord always takes 5000 years and 5 minutes to launch so WebCord has consistently always started first

[SpacingBat3]

I've managed to do some "fixes" on my side, but Discord still keeps spamming WebCord's WebSocket.
I guess the one should report this issue on their side as StreamKit doesn't work when primary port is reserved by another app/WebSocket. A proposed solution on the Discord side would be to either limit how many requests it can send before switching to the next address or respond to any failure (close event) immediately.

You may think why WebCord uses WSS on the same port as Discord and the answer is simple: for communication with browser. While it doesn't support all requests, it can reply to some (like this). Even ARMCord has took the part of WebCord's code and uses it at the border of the legality (and it's sus they've locked up the conversation on this topic and not fixed the issue in the affected releases – or at least respond why they didn't do that as I was expecting when trying to contact them again) to implement this feature. (EDIT: there's a reply on this topic, so at least I got more information about this, which I was requesting for.)

[SpacingBat3]

I'll close this as wontfix, WebCord does not support requests that requires API to be resolved (SteamKit wants from WebCord to respond to AUTHORIZE request) and it is in general a bug on the Discord's side (I've described why I think that way in previous comment). As a side note, I believe setting up any WebSocket Server (without caring about the communication at all) has potential to be a denial-of-service for Discord client, blocking entire communication for stuff like RPC (based on WebSocket; Discord also uses IPC for RPC), invite links etc.

[SpacingBat3]

@3e849f2e5c I've reported the bug to Discord, hopefully they will improve their implementation of WebSocket client on StreamKit to solve this so it will ask Discord client once WebCord closes the connection.