The MVP seems extremely simple to me. Because WebRTC more or less "just works", if it has a list of peers! It's a miraculous age. Sure, it's a limited set of "just works", it doesn't scale to 50 users, but there are demos that use less than a dozen lines of code to let the user manually enter IP addresses & start video chatting with a couple friends, in a nearly universal manner.

To me, it feels like there's only one thing missing, & it's pretty basic. There's dozens of different choices for signalling servers, to help figure out who to peer with in webrtc. But they are all single-origin centric. All that's really needed to begin to allow cross-service video conferencing is a signalling service that can collaborate across domains. Some protocol to let the two signalling services exchange peers with each other.

> and there's absolutely zero consensus on how to standardize any of it.

The ecosystem feels beholden to a very vendor-centric project-centric perspective. I don't think most folk who deal with webrtc have much interest in trying to work together, to try to standardize. Which is really sad, because I think forming some good core basis to begin to work together from would help us all move much faster.

> All that's just basics before we get into even the simplest extra but still required features like raising your hand, chat, file transfer in a chat, and so on.

Yet another reason why I am 98% convinced that xmpp is actually what we need to do all our signalling atop. MUJI was ok[1]. We need to rebase it from the crufty/bad MUC/Multi-User-Chat system to work atop the newer[2] MIX/Mediated Information eXchange system. Either one will "solve" almost all these federated peering questions, easy. Then we can go about figuring out how relays &c work in this world.

And with that basis, 80% of these other concerns would be weekend projects to write specs from. Raising hands? Done. Chat? Already have that. File transfer? Well specified.

You're right that there are a lot of questions, problems, issues. But mainly I think it's the lack of will to tackle this problem in a cross-domain manner that's holding things back, and that is keeping us kind of tied into this cruddy local maxima, a bunch of competing products, versus a more dynamic interesting & useful & evolving space. I see plenty of people hemming & hawing & complaining about XMPP clients having different feature sets, but in practice, things work extremely well. Detecting & notifying when someone's client isn't capable is usually handled very gracefully & clearly. The Fear Uncertainty & Doubt, it feels to me, often is unwarranted; for the most part it turns out highly extensible systems work quite well & robustly & the occasional mismatches can be dealt with in a quick manner, & hopefully, over time, more consensus emerges & good features roll out. For ex, OMEMO encryption once was rare in XMPP, now it's expected.

I don't know how to sum this all up. Because I recognize what you are saying, and there are bedevilling complexities in all of this. But it also feels imminently close, doable, especially if we rely on the really good tech we already have (XMPP, &c), which seems like it should suffer many of these same problems, but which, it turns out, works pretty great. I don't see the barriers to the better world as technical. I see us as spending a lot of time building independently, & coming up with excuses for why we are not building together. And I think few folks working with WebRTC prioritize interoperation at all, which is a huge root cause of the slowness of the universe.

[1] https://xmpp.org/extensions/xep-0272.html

[2] https://xmpp.org/extensions/xep-0369.html#concepts-muc-compa...