Firstly - @dmonad, thank you and the community for creating this amazing library! It is an incredible piece of work.
I am experiencing an issue where when using WebRTC, sometimes peers don’t seem to find each other and I am not sure why. It is too sporadic for me to recreate consistently, but I got “lucky” today and ended up in a state where an InCognito window of chrome did not properly connect to the room I had open in my regular window. Didn’t see any errors; had the signaling server hardcoded (to one of the defaults). I logged the provider and the room/password seemed consistent across the non-connected peers.
What’s interesting is that new tabs in that InCognito window would successfully connect to their own “instance” of the room but would not connect to the peers in the regular window. New tabs in the regular window in turn connected to each other but not to the InCognito peers… Here’s the kicker - when I connected to the room from my phone (in cognito on there too), all peers suddenly connected to each other. Now I could see all edits across any of the 3 “users”. When I left the room on my phone, the peers would disconnect from each other once again creating the isolated silos (InCog tab users together, regular tab users together).
I am not sure what to make of this. It seems like something is blocking the peers from discovering each other, but I am not sure why accessing it from another device enables that discovery. I tried using peerOpts to specify a different set of iceServers (Free WebRTC TURN Server - Open Relay Project | Open Relay Project - Free WebRTC TURN Server) but that didn’t make a difference either. It also seems like there is something about the browser instance/profile that could be influencing the connection path (since tabs across the instance connected to each other).
How might I go about troubleshooting this further? Crossing my fingers the problem persists so I can get to the bottom of it