Good to see your replies as well as more comments. Even more comments would be good from people conferencing all the time. I definitely didn't want your message to drop too far down.
I don't think overcomplication is the problem. Once the core code is good enough, that could all be smoothed out by UI refinement. I would pick one single computer language to make the entire thing fully functional at least under CLI, then in case any other language was better for UI that could be layered on afterward.
What's really missed badly is something that can stand the test of time on its own, with only the most minimal dependencies, and from the ground up is peer-to-peer without any need for an "account" or reliance on email to do everything that is needed.
Everybody in the meeting should be able to download the same app, populate their "phone" directory manually or from a standard text config file (intial config layout MUST be well standardized to begin with, to withstand any possible update anticipated, and then some). This is where you really get to write the rules from the ground up so take advantage of it. Especially your "standardization" role.
The only reason this is still needed is that nobody else has stepped up to the plate to serve in that role, and it's been since 1997.
There's webcam standards, video standards, audio standards, all which didn't exist back then or were different than today.
Ideally anybody on the internet with a cam, mic and speakers should be able to simply run the app locally without "installation" even, choose the local cam and audio devices they want to use as provided by the OS, then take the position as either moderator or participant. With a phone book built from simple text that could easily be communicated orally over cellphones for small meetings, everyone could actually maintain the same directory at all times, but it would be the moderator or initiator who clicked on each of the intended participants to build the group communication. Then each of the participants would only have to respond-click to that one moderator's "phone" number. Not much different than Intel started out doing, with either person initiating the videocall, and the other party answering. Then "everybody" pops up on everybody's screen at the same time, but there was only a single other party back then.
Or it might make sense for the underlying code to allow for or require participants to click (or autoconfig) their "choice" of other participants they want to allow the peer-to-peer communication with during a particular meeting, and no others.
Until you get going and depend on decorum from there . . .
Edit: I guess worthwhile design criteria I would use is that there should be no need for internet communication between parties to begin with, until the meeting is actually joined, serverless between peers only. Although getting a little private network going from something like Wireguard beforehand might be a good option, after which your app would behave the same way whether it was Wireguard, something else, or nothing at all.
