On 4/6/20 9:48 AM, Eric Rescorla wrote: > > > On Mon, Apr 6, 2020 at 8:28 AM Michael Richardson <mcr+ietf@xxxxxxxxxxxx > <mailto:mcr%2Bietf@xxxxxxxxxxxx>> wrote: > > > Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx > <mailto:phill@xxxxxxxxxxxxxxx>> wrote: > > We need an open standard for such a client. Because that is > the only way > > users can be assured the client they are downloading hasn't > got a backdoor. > > It isn't a perfect guarantee but it is better than the > situation I have now > > where my messaging provider reconfigures its app every ten > days or so. > > Being forced to install code updates from a single source is a > security > > risk in itself. And don't tell me that frequent updates are > necessary for > > security, if the code is so buggy it has to have an urgent > security patch > > more than once a month, you are doing it wrong. > > This. > > Lots of people have explained why XMPP sucks, but I prefer the suck > I know > and foster some competition without a fork-lift upgrade, to the > single source > of code (no matter how "open" source it is). > > I don't think that the IETF is going to get anywhere with > standardized video > conferencing. > I don't think W3C will either (I think they have less of a chance > actually). > > WebRTC is a good start, and I'm happier with javascript I have to > download > and trust than native code I have to download. > > Having said this, eating our own dogfood is really important. > IPv6, webrtc, QUIC, TLS1.3. > > I understand from this thread that webrtc solutions can *not* send p2p > streams between end points? > > > No, they can. However, many WebRTC-based conferencing systems still > use a centralized topology, for a variety of reasons. Among other things, a selective forwarding unit is needed in order to scale a videoconference beyond 3-4 participants (because few devices can decode more video streams than that at once). Peter
