Phillip Hallam-Baker <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? I find this surprising, since I observe failures in webrtc which seem to be lack of a clear n X n media flow. (Alice and Bob can talk, and Alice and Carmen can talk, but Bob and Carmen can't talk) -- Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works -= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature