On Mon, Apr 6, 2020 at 8:28 AM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
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?
No, they can. However, many WebRTC-based conferencing systems still
use a centralized topology, for a variety of reasons.
-Ekr
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 =-
