►
From YouTube: Why WebRTC - Ryan Plauche, Max Inden
Description
This talk was given at IPFS Camp 2022 in Lisbon, Portugal.
A
Why
webrtc
and
we'll
dive
into
yeah
we'll
continue
from
Martin
I,
don't
know
where
Martin
there's
Martin
well
continue
for
Martins
and
Alex
talk
and
go
a
little
bit
deeper
into
the
other
protocol,
which
is
webrtc
cool,
I'm,
Max,
I.
Don't
think
I
need
to
introduce
myself
again.
This
is
Ryan.
Do
you
want
to
introduce
yourself.
B
Yeah
so
I'm
Ryan
I
work
for
little
bear
labs
and
really
that's
the
important
part
here
is
the
little
bear.
Labs
part
I'm,
just
a
representative
of
my
colleagues
and
the
wonderful
work
that
they've
been
doing
on
lib
P2P
helping
implement
this
web
RTC
transport.
So
any
appreciation
or
thanks
that
you
have
for
this
work,
really
should
go
to
John
and
chinmei
from
the
little
bear
Labs
team
you
can
find
them
on
the
filecoin
slack
or
the
ipfs
Discord,
and
if
you
want
to
learn
more
about
little
bear
Labs.
A
Yeah,
cool
okay,
so
what
I'm
gonna
do
is
walk
us
a
little
bit
through
the
history
of
webrtc
in
lipidappy
and
then
Ryan
at
the
end
is
going
to
give
a
demo
of
what
we
have
yeah
in
the
making.
A
Wonderful,
okay,
Martin
already
did
most
of
this.
What
does
whatever
it's?
The
well
a
pretty
old
protocol?
At
this
point,
many
many
rfcs,
we
jokingly
sometimes
say
like
it,
combines
all
the
rfcs
out
there
into
one.
A
It
does
the
audio
and
video,
as
Martin
already
said,
and
the
big,
the
big
things
for
us
for
webrtc
are
not
to
mod
audio
and
video,
but
the
RTC
data
channels,
so
a
way
how
to
transmit
data
in
a
bidirectional
or
how
to
transmit
messages
in
a
bidirectional
way
between
two
endpoints
yeah
over
sctp
over
dtls,
over
UDP
and
so
on.
A
The
two
big
properties
for
us
are
a:
it
allows
certificate,
verification
by
certificate,
hash
or
fingerprint,
and
it
might
sound
a
little
bit
cryptic.
But
what
that
translates
to
is
we
can
make
a
connection
to
another
peer
without
that
other
peer
having
assigned
like
properly
trusted
certificate.
A
So
we
can
make
a
connection
to
a
peer
that
has
a
self-signed
TLS
certificate,
that's
big,
because
that
takes
a
lot
of
the
setup
work
on
the
maintainers
of
servers
and
nodes
out
there
and
not
having
to
spin
up
DNS
to
the
let's
encrypt
dance
and
so
on,
and
then
the
second
property.
The
big
thing
forward,
C
for
us
is
hole
punching,
so
webrtc
actually
allows
us
to
hole
punch
from
the
browser
right.
The
browser
is
a
very
restricted
platform,
that's
a
good
thing,
but
we
don't
have
access
to
the
UDP
and
TCP
sockets.
A
So
it's
impossible
for
us
to
build
our
own
hole
punching
within
the
browser
with
the
browser
with
webrtc
basically
takes
that
takes
care
of
that.
For
us
we
just
need
to
properly
use
it
all
right.
So
now
we're
not
the
only
people
that
discovered
wherever
C
right,
like
there's
a
long
long
history
of
web
HC
and
it's
actually
actively
being
used
today
within
Liberty.
A
There
is
one
project
which
is
JS
Liberty
webrtc
star,
so
you
have
a
central
turn
and
stun
servers,
and
then
you
coordinate
via
the
servers
and
that
allows
two
browsers
to
connect
to
each
other
and
then
another
one
is
sorry
and
take
it.
This
way
just
live
to
be
direct.
A
That
is
basically,
you
do
a
connection
to
a
server.
For
example,
with
your
websockets,
you
exchange
your
session
description
protocol
packets
via
that
server,
and
then
you
can
fall
back
onto
a
web.
Rc
connection
actually
actually
establish
a
webrtc
connection.
In
addition
to
that
Okay
cool.
So
a
couple
of
problems,
Weber
Z
Star.
We
need
the
central
stun
and
turn
infrastructure.
Now.
This
is
called
lib
PDP,
like
library,
for
peer-to-peer
it's
a
bummer
that
we
need
to
depend
on
anything
Central
right.
A
So
that's
one
problem
for
us
and
then
the
second
one
for
lipid
to
be
whatever
C
Direct.
If
I
need
a
websocket
connection
to
exchange,
the
sdps
I
already
require
the
node
to
have
a
valid
TLS
certificate,
and
thus
I
run
again
into
the
problem
that
everyone
has
to
get
the
domain
and
well
get
has
to
get
a
valid
TLS
certificate
right.
So
we
basically
want
to
do
better
than
these
two,
even
though
they
already
get
us
very
far
within
Liberty.
Today,.
A
Now
it's
quite
a
history.
You
see
here
the
the
year
2019
Stephen
had
the
idea,
let's
let's
put
more
work
into
this.
Let's
drive
this
further.
Eventually
we
picked
this
up.
Do
you?
Is
there
a
date
on
there
I
think
May
11th?
We
picked
this
up.
It's
a
pretty
big
spec
at
this
point
and
we
have
two
efforts:
improving
what
we
have
when
we're
about
to
see.
A
One
use
case
is
browser
to
server.
Martin
already
mentioned
that
I'll
go
a
little
bit
into
detail
here.
With
this
new
webrtc
effort,
we
can
connect
from
a
browser
to
a
server
with
no
dedicated
stun
or
turn
server.
We
still
need
the
stun
protocol
between
the
browser
and
the
server,
but
there
doesn't
need
to
be
any
third
party
and
that's
wonderful,
because
now
we
can
make
that
connection
without
that
server
having
a
valid
DLS
certificate
within
our
trust
chain.
A
For
those
familiar
with
the
many
rfcs,
this
is
based
on
Ice
light.
We
Multiplex
on
the
UDP
socket
on
the
server
side.
It
requires
an
additional
noise
handshake
that
you
have
seen
in
the
rtt
measurements,
not
measurements,
counting
that
Martin
did
earlier
the
status.
As
Martin
already
said,
we
have
a
specification
close
to
VMware
analyze
and
implementations
in
JS,
go
and
rest,
and
just
to
stress
this
one
more
time.
What
this
enables
us
to
do
is
do
a
connection
like
with
web
transport.
A
Do
a
connection
from
the
browser
to
a
server
without
that
server
having
a
valid
DLS
certificate,
then
the
second
use
case
which
webrtc
will
enable,
but
we're
still
far
away
from
that-
is
browser
to
browser
without
any
Central
Central
infrastructure.
For
now,
that's
all
right.
We
actually
have
a
whole
talk
on
this
in
a
little
bit,
so
so
browse
it
to
browser
without
any
Central
infrastructure.
Again
we
have
webrtc
star
today,
which
does
allow
that
already
today,
but
has
the
dependency
on
Central
infrastructure.
A
This
is
only
draft
for
now
reach
out
to
me
in
case.
You
want
to
talk
about
that
plenty
of
thoughts
already
went
into
that.
It
still
requires
done
servers
and
right
now,
I,
don't
see
a
way
how
to
get
around
stunt
servers,
but
the
cool
thing
is
the
two
nodes
that
want
to
connect:
don't
have
to
connect
to
the
same
stunt
server
so
we're
this
is
fine.
I
think
this
is
a
bullet
to
worth
worth
to
write,
yeah
cool.
Okay.
A
B
Awesome
yeah
so
I'm
going
to
show
this
demo.
So
what
we've
got
is
we're
going
to
run
two
go
listeners
and
we
have
a
react
app,
which
holds
our
JS
lib,
P2P
dialer,
and
what
we
can
do
is
we
can
copy
this
multi-address
from
our
go
listener
and
paste
it
in
here
and
we'll
all
cross,
our
fingers
and
dial
and
oh
look
cool.
So
we
have
a
little
connection
now
with
our
go
listener.
B
If
we
want,
you
know,
we
can
temp
fate
again
and
connect
to
another
one
and
see
Okay
cool.
So
now
we
have
this
little
peer-to-peer
network
with
the
one
browser,
client
and
the
two
go
servers.
And
then
you
know
we
can
say
hello.
B
To
Mr,
44.
and
yeah,
we
can
see
using
the
echo
protocol
messaging
back
and
forth,
but
I
feel
like
there's.
It's
like
another
question
here.
Right
like
how
do
we
know
this
is
webrtc
I
could
have
just
copied
Alex's
web
transport
demo
and
like
had
it
print
out
webrtc
and
the
multi-address
and
be
tricking
all
of
you.
So
maybe
there's
like
another
way
that
we
can
know
and
chrome
gives
us
this
really
cool
tool,
this
webrtc
internals
page.
B
So
we
can
go
to
this
graph
for
this
data
Channel
and
we
should
be
able
to
watch
now
if
I
send
another
message
to
b57.