Despite this WebRTC work being largely uninteresting (as it is basically just front-end stuff), I do seem to have it basically working. For this system, I am going with something simple: Starting a "chatroom" data channel and video/audio stream prior to connection and only allowing 2 users. This will skip the peer connection restart/upgrade logic and also avoids needing to keep the WebSocket open to the server (to allow other users to late-join) and simplifies the peer connection management logic, in general (as there is only 1 other peer).

For testing, the system is currently relying on BroadcastChannel (which is something I wasn't aware of and simplified this initial experimentation dramatically). This obviously won't work, in general.

So, the plan is to clean up this minimal experiment as the first commit, then introduce a minimal BreakWater server with the WebSocket end-point and cut-over to that as the second, then I need to get my own server's HTTPS running and figure out how to deploy this such that I can stitch this feature in to other generic content at the configuration level.

These steps should be relatively straight-forward but none of them really interest me so the drive to get it done is scarce. At least I do seem to always get inspired to work late at night, so maybe that will help (it worked, yesterday).

Then, of course, I will have to see how well it actually works across a real network or if the UDP hole-punching doesn't work in the relevant cases.

Here's hoping,
...Nights