Re: Off-topic: making WebRTC work in practice (Re: a brief pondering)

[Eric Rescorla <[e-mail]>]

On Mon, Apr 6, 2020 at 8:28 AM Michael Richardson <[e-mail]>
wrote:

>
> Phillip Hallam-Baker <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>