►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
lipid2p,
what?
What
do
we
do
in
the
P2P
we
mostly
deal
with
connections
between
between
nodes
connection
is
a
point-to-point
connection
between
two
nodes.
We
have
a
lot
of
different
a
lot
of
different
connection
options
because
there's
no
one-size-fits
all
as
we
will,
as
we
will
explore
in
this
talk,
so
nodes
offer
different
connection
options
to
be
to
be
widely
accessible
to
the
network
and
connections.
A
Are
we
use,
multi
addresses
to
for
for
addressing
nodes,
and
you
can
see
here,
multi
address
for
TCP
and
the
multi-address
for
for
quick,
just
very,
very
quick
recap
what
what
Lupita
p
connection
is.
It
provides
security,
there's
no
such
thing
as
an
unencrypted
w2p
connection,
so
we
run
a
handshake
which
gives
us
gives
us
the
encryption,
and
we
know
the
the
remote's
peer
ID
after
the
handshake.
A
The
connection
is
also
always
always
stream
multiplexed
on.
If
for
quick,
you
get
this
for
free,
because
quick
has
streams
at
the
transport
layer
for
transports
that
don't
have
streams
at
the
transport
layer.
We
do
an
upgrade
process
and
use
a
stream
stream
multiplexer
to
provide
streams
to
the
application.
So,
every
time
an
application
uses
a
lipidop
connection,
it
looks
like
it.
It
just
has
the
strings
and
we
deal
with
all
the
complexity
below
that.
A
So
I've
I've
shown
this
this
table
a
bunch
of
times
over
the
last
over
the
last
half
a
year
and
it
looked
very
different
when
I
started
doing
this
presentation,
there
was
a
lot
more
red
there
and
I'm
very
happy
to
report
that
we
are.
We've
made
a
lot
of
progress
in
the
last
half
a
year,
so
let's
go
go
through
it.
A
The
most
basic
connection
option
is
TCP.
We've
supported
lipidopia
supported
that
for
I,
don't
know
since
basically
since
since
the
very
beginning
six
years,
seven
years
so
that
that
works
that
works
in
go
lipid3,
it
works
in
Rust
w2p.
It
does
not
work
in
the
browser,
though,
because
the
browser
doesn't
allow
you
to
establish
a
a
raw
TCP
connection.
The
browser
allows
you
to
to
establish
HTTP
connections,
that's
what
it
does
all
the
time,
but
it
doesn't
give
you
access
to
the
to
the
underlying
TCP
connection,
similar
for
quick.
A
We
added
quick
support
a
little
bit
later,
maybe
four
years
ago.
Now
it's
been
in
in
go
lipidop.
We
are
very
soon
getting
quick
support
in
Rusty
P2P,
so
that's
very
exciting,
but
then
for
browsers
same
problem.
The
browser
does
quick
connections
as
part
of
HTTP
free,
but
it
doesn't
give
you
access
to
the
underlying
quick
connection,
so
what
do
browsers
browsers
use?
Instead,
they
are
basically
three
protocols
that
browsers
can
use
and
we'll
take
a
look
at
them
today.
A
A
There's
a
new,
a
new
transport
protocol
around
called
Web
transport,
which
is
Now
supported
by
golo
P2P.
As
of
the
last
release
and
there's
webrtc,
where
we
have,
we
have
been
working
on
this
for
for
the
last
six
months
and
we've
made
a
lot
of
progress
and
we'll
be
shipping
that
very
soon
more
more
of
that
later.
A
So,
let's
have
a
look
at
websocket
web
socket
is
a
pretty
old
protocol.
The
RFC
is
for
from
2011.,
basically
what
it,
what
it
allows
you
to
do
is
to
take
an
HTTP
Connection
in
the
browser
and
to
convert
that
into
a
full
duplex
connection.
A
So,
basically,
what
you
do
is
you
establish
the
HTTP
connection
to
the
browser?
Ask
the
browser
hey?
Can
we
can
we
upgrade
this
connection
to
to
websocket
and
then
the
browser?
That's
the
request
printed
down
here
and
then
the
browser
can
say
like
yeah,
I'm.
Okay
with
that
Let's
do,
let's
do
websocket
over
this
connection,
and
what
this
means
is
that,
instead
of
doing
HTTP
requests
and
responses
on
the
on
the
connection
is
that
you
get
access
to
like
a
full
duplex
connection.
You
can
send
bytes.
The
browser
can
send
bytes.
A
A
Specifically
what
that
means
is
that
if
you
have,
if
you
load
a
web
page
over
an
https
connection
of
an
encrypted
connection,
it
will
not
allow
you
to
do
unencrypted
websocket
from
from
that
web
web
page.
If
you
do
that,
you
get
this
beautiful
error
message.
There.
A
So,
what's
the
problem
with
that
to
do
an
encrypted
websocket
connection,
you
need
a
TLS
certificate
like
the
server
needs,
a
TLS
certificate
and
Mo
to
together
and
to
get
a
TLS
certificate.
You
need
to
contact
a
certificate
Authority
like
let's
encrypt,
or
there
are
a
bunch
of
other
ones
around,
and
you
need
to
get.
You
need
to
get
the
certificate
from
there.
A
Even
worse,
most
certificate
authorities,
don't
give
you
a
a
certificate
for
an
IP
address,
but
they
require
a
host
name
now,
most
lipid2p
nodes
on
the
network.
It's
just
people
running
their
node,
they
don't
they.
They
might
not
even
have
a
host
name,
and
we
don't
want
to
tell
tell
people
like
you
need
to
go
to
the
CA
and
get
the
certificate
and
then
somehow
configure
your
node
to
use
that
certificate.
A
A
Another
problem
with
the
websocket
is
that
it's
quite
slow.
If
you
count
the
round
trips,
you
have
one
round
trip
for
the
TCP
handshake.
You
have
one
round
trip
for
the
TLs
handshake.
You
have
another
round
trip
for
the
websocket
upgrade
and
then
lipid2p
kicks
in
and
takes
another
three
round
trips
to
negotiate
a
security,
mod
protocol
and
the
three
multiplexer.
So
in
total
we
end
up
with
six
round
trips,
which
is
very
expensive.
Now
we
can
improve
a
little
bit
on
the
lipid2p
part
and
not
waste
so
many
round
trips.
A
On
on
on
the
multi-stream
negotiations,
we
can
cut
this
down
by
by
two
round
trips,
and
this
will
be
rolling
out
in
the
in
the
next
in
the
next
few
months
in
golo
P2P,
but
we
are
still
like.
We
can't
do
any
better
than
four
four
round
trips
to
set
up
a
websocket
connection.
A
Now
the
new
protocol
web
transport-
it's
super
exciting,
it's
still
under
development,
so
there's
no,
no
Roc
yet,
but
the
ITF
is
working
on
this
and
the
w3c
is
standardizing
a
browser
API.
A
It
runs
on
top
of
http
3.,
it's
always
encrypted,
because
it's
because
it's
quick
and
it's
it's
basically
the
same
thing
as
websocket
from
a
conceptual
standpoint,
but
you
don't
get
access
to
to
the
underlying
TCP
connection,
but
you
get
access
to
to
the
to
the
native
quick
streams
of
the
connection.
So
that's
pretty
cool
because
you
get
all
the
all
the
benefits
you
you
have.
A
You
have
of
quick
as
compared
to
TCP
the
upgrade
works.
Pretty
similar
you
send.
You
send
a
request
to
the
server
asking
for
that
upgrade
to
to
web
transport,
and
then
the
server
can
can
accept
that
and
from
then
on
one
can
use
one
can
use
the
quick
streams.
A
The
server
also
requires
the
connection
to
be
secure.
So
it's
we
for
the
longest
time
we
thought
like.
Oh,
this
will
just
be
the
same
as
websocket,
but
then
earlier
that
was
earlier
this
year.
I
think
it
was
in
January
the
w3c
decided
to
introduce
a
new
browser
API
it's
intended
for
short-lived
VMS,
that
don't
have
domain
names
and
that
don't
have
that
don't
have
TLS
certificates.
So
it's
basically
exactly
what
with
what
we
had
been
hoping
for
in
lip
P2P
for
so
many
years.
A
The
way
this
works
is
when,
when
the
browser
knows
the
the
certificate,
the
the
hash
of
the
certificate
that
the
browser
will
present,
it
will
accept
this
as
a
secure
connection,
just
as
it
would,
except
as
a
certificate
that
was
signed
by
a
CA.
So
there's
these
two
options:
you
can
either
give
the
browser
a
ACA
signed
certificate,
or
you
can
tell
the
browser
about
the
hash
before
that,
and
then
the
browser
will
just
check
that
the
certificate
you
present
during
the
handshake
actually
matches
that
hash.
A
There
are
a
few,
a
few
restrictions
that
come
with
this.
You
cannot
use
an
RSA
key,
that's
pretty
pretty
pretty
easy
to
work
around.
We
don't
use
RSA
keys
anyway.
The
other
one
is
that
the
certificate
must
be
short-lived
because
they
were
targeting
these.
These
VM
deployments
there's
a
limit
on
how
how
long
the
certificate
can
be
valid,
and
we
have
to
work
around
that
in
in
lipid2p,
because
the
this,
the
the
maximum
validity
time
of
the
certificate,
is
14
days.
A
We
do
this
by
basically
advertising
multiple
multiple
certificate,
hashes
in
in
the
multi-adders,
as
you
can
see
down
here,
so
this
all
works.
We
ship
this
in
the
latest,
goly
P2P
release
as
an
experimental
transport
and
we'll
probably
make
it
a
default
transport
in
our
next
release.
A
Let's
count
to
round
trips
again
it's
a
lot
faster
than
websocket.
We
just
have
to
do
a
quick
handshake.
We
then
have
to
do
a
the
web
transport
connect
request
and
then
we
then
lipid2p
runs
another
noise
handshake
on
a
web
transport
stream.
So
we
are
at
just
three
handshakes
and
with
one
optimization
that
will
soon
be
possible
when
the
w3c
fixes
their
browser
API,
we
can
run
the
the
second
and
the
third
step
in
parallel.
So
we'll
be
down
to
two
just
two
round
trips
to
fully
set
up
a
little
P2P
connection.
A
So
I
I
have
a
a
quick
demo
of
how
this
works.
Marco
built
this
Marco
from
the
lp2p
team
built
this
demo,
there's
a
there's,
a
Kubo
node
running
web
transport
by
provided
by
Google,
P2P
and
he's
connecting
to
it
from
the
browser
you
see.
There's
the
multi
address
containing
the
hashes
already
established
the
connection
and
he's
now
downloading
a
CID
from
a
kubernet
directly
in
the
web.
Browser
and
I
was
too
slow.
Not
writing
this,
but
it
isn't.
Okay,
I'll!
A
A
So,
given
that
the
file
car
network
is
already
running
on
the
P2P,
we
could
we
could
create
transaction
five
coin
transactions
in
the
browser
and
directly
submit
them
to
the
to
the
mempool
via
the
gossip
sub
protocol
So.
Currently,
when
you
use
an
application
like
glyph
to
to
send
to
send
some
file
coin
around,
they
would
connect
to
it
to
a
Gateway
node.
You
would
sign
the
transaction
in
your
browser.
Send
that
to
the
Gateway
and
the
Gateway
would
then
put
this
on
gossips
up
to
to
get
the
the
the
transaction
into
the
blockchain.
A
A
Another
thing
that
that
is
that
is
possible
now
is
you
could
potentially
make
a
file
coin
deal
right
from
your
brow,
browser
and
upload
the
the
data
to
the
storage
provider
using
web
transport,
and
then
it
it
should
also
work
the
other
direction
you
could.
You
can
retrieve
data
from
any
ipfs
node
we've
already
seen
that
in
the
demo,
and
potentially
this
could
also
work
with
Falcon
nodes.
You
could
retrieve
retrieve
data
from
FICO
nodes
using
web
transport.
B
Cool
okay,
the
last
one
on
the
list
is
Weber
to
see.
Most
people
have
probably
heard
the
term
webpage
see,
and
most
people
here
probably
also
use
webrtc,
it's
quite
it's
quite
old
and
we
jokingly
say,
like
it
probably
defy
uses
every
RFC
that
the
iftf
ever
standardized
in
one
protocol,
it's
initially
built
for
audio
and
video.
So
most
of
you
are
probably
at
some
point
used
Hangouts
to
connect
with
two
people
and
you
might
have
used
webrts,
either
to
actually
transfer
the
video
bytes.
B
Now
lipidly
is
not
focused
on
video
or
audio,
but
instead
reliable
data
channels,
but
the
cool
thing
about
webrtc.
The
browser
apis
actually
give
us
a
way
to
send
data
in
a
reliable
way
over
these
things
called
RTC
data
channels.
So
you
can
think
of
that
just
yeah
as
a
bi-directional
message:
Channel,
where
you
can
send
message
in
and
get
messages
out
for
those
interested
that
runs
on
top
of
sctp
that
runs
on
top
of
ttls
and
that
runs
on
top
of
UDP.
B
So
now
you
can
get
a
graph
where
I
say
like
this
combines
every
RFC
out
there
cool.
So
two
properties
which
are
for
us
important
are
three
one.
Is
this
RTC
data
channel
right?
We
can
send
messages
between
two
nodes.
Second,
one
is
similar
to
web
transport.
This
allows
us
to
connect
to
a
node
that
doesn't
have
a
science
certificate
by
a
certificate
Authority,
so
it
allows
us
to
make
a
connection
to
a
node
where
we
only
have
the
certificate
hash.
B
Of
that
note,
cool
and
then
the
second
thing
or
the
third
big
thing
is
that
allows
us
to
do
hole
punching
with
the
browser,
so
usually
browsers
are
always
behind
Nats
and
firewalls
right.
No
one
allows
us
to
connect
to
that
browser
from
the
outside
so
now
with
webrtc.
We're
actually
allow
able
to
connect
two
browsers
with
each
other,
and
that's
probably
also
how
you
have
your
video
call
over
Hangouts
at
some
point
in
time:
cool,
okay,
so
that's
webrtc,
and
now
we
want
to
use
webrtc
and
Liberty,
and
we
have
two
use
cases.
B
One
is
browser
to
server
and
they're.
Really.
The
relevant
part
is
like
in
web
transport.
We
want
to
connect
to
a
server
that
doesn't
have
a
signed
certificate
by
a
certificate
Authority
right
most
of
the
ipfs
network.
For
example,
most
of
the
nodes
are
just
people,
spinning
up
nodes
in
their
home
network
or
on
servers,
and
they
don't
want
to
go
as
Martin
described
through
getting
a
domain
and
so
on.
B
So
webrtc
gives
us
that
and
we
can
actually
do
a
webrtc
establish
a
webrtc
connection
from
a
browser
to
a
server,
so
a
public
endpoint
without
stun
in
turn
for
those
familiar
with
webrtc.
Usually
it
always
requires
a
dedicated
stun
internet
server
somewhere,
but
we
don't
need
that
and
that's
like
a
great
step
for
Liberty
to
actually
establish
in
a
peer-to-peer
fashion
connections
as
we
don't
need
either
of
those
for
those
interested
like
we
all.
This
is
based
on
Isis
light.
B
This
allows
us
to
to
multiplexing
on
the
UVB
socket,
but
that's
really
too
much
into
detail.
So
if
you
want
to
know
more
about
how
we
get
around
stun
and
turn
reach
out
to
me
and
I'll,
explain
to
you
more
in
detail,
cool
webrtc
gives
us
with
ttls
gives
us
some
security,
but
we
haven't
authenticated
the
remote
yet
the
lipidopy
identity
of
the
remote.
B
So
none
of
this
was
merged
and
none
of
this
is
released,
but
we
hope
to
get
that
to
that
at
some
point
soon,
cool
so
Martin
had
all
the
cool
protocols
where
he
could
count
round-trips
here
on
the
stage
I'm
now
presenting
webrtc,
where
you
probably
don't
want
to
count
the
round
trips,
but
obviously
that's
a
joke.
Let's
count
the
round
trips,
it's
not
that
bad.
B
We
have
a
stun
exchange
again,
not
a
dedicated
Sun
server,
but
just
with
that
server
that
you're
trying
to
connect
to
so
still
in
a
peer-to-peer
way.
Then
exchange
that
one
round
trip
we
have
dtls
handshake,
that's
two
round
trips.
We
have
sctp
basically
basically
giving
us
TCP
on
top
of
UDP
but
more
to
this
two
round
trips,
and
then
we
have
a
noise
handshake,
one
round
trip.
B
B
What
we
want
is
obviously
to
for
two
browsers
to
connect.
Browsers
can
already
do
that
with
webrtc.
They
can
do
hole
punching,
which
is
great.
We
just
need
to
make
use
of
it
in
lipidop
and
we
want
to
do
that
in
a
peer-to-peer
fashion,
so
ideally
at
least
not
depend
on
any
relay
servers
or
coordination
servers
yeah
right
now.
This
is
a
draft
only
so
definitely
not
a
pending
to
be
merged
specification.
B
As
far
as
we
can
tell,
we
only
need
stun
servers,
but
the
nice
thing
about
stunt
servers
for
those
familiar.
The
two
peers
that
want
to
connect
don't
need
to
be
connected
to
the
same
stunt
server.
So
this
can
be
any
stun
server
out
there.
Obviously
we
could
use
the
Google
stun
servers,
but
also
many
many
companies
can
run
stunt
servers
and
we
we
use
any
of
them.
B
We
don't
need
turn
servers.
That's
the
nice
thing.
We
can
relay
everything
over
the
Liberty
Network
and
thus
still
establish
Connections
in
the
peer-to-peer
fashion,
cool,
okay,
use
cases
for
all
of
this,
so
you
want
to
use
webrtc
in
case
web
transport
doesn't
work
for
you
because
in
general
web
transfer
it
will
be
a
lot
faster.
It's
on
the
newer
stack
and
it
will
need
less
round
trips
to
establish
the
connection
now
in
case
web
transport
doesn't
work
for
you
use
webrts
and
then
for
the
Second
Use
case,
which
is
browser
to
browser.
B
You
can
use
this
for
so
many
things
again.
I
think
our
creativity.
There
is
way
more
beyond
our
creativity
here.
The
easy
and
boring
use
case
that
probably
everyone
thinks
about.
Is
you
have
two
browsers
next
to
each
other
and
you
want
to
exchange
a
file
or
you
have
a
browser
here
in
the
browser
in
America
and
you
exchange
a
file
in
a
PHP
fashion.
B
Cool
and
then
fire
fire
fire
in
the
future
I
would
I
really
like
to
see
this
mesh
style
where,
like
the
conference,
Wi-Fi
is
off
and
we
can
still
exchange
files
over,
for
example,
a
QR
code
and
then
connect
to
each
other
and
then
exchange
the
files
in
the
peer-to-peer
fashion.
But
the
last
one
definitely
not
on
our
short-term
workmap
cool
should
I
move
on
yeah.
A
Yeah,
thank
you
for
coming
to
our
talk.
We
have
launched
a
website
explaining
all
the
different
connectivity
options
in
the
P2P,
because
we
realize
there's
there's
a
lot,
there's
a
lot
of
trade-offs
so
head
to
connectivity.liby2p.io,
and
you
will
find
all
the
information
there,
including
links
to
the
PRS
and
the
ongoing.
B
Work
and
one
more
thing
we
have
on
Sunday:
we
have
Liberty
Day
part
of
ipfs
Camp,
so
you'll,
if
you,
if
you
like
this
talking
and
if
you
want
to
see
other
people
talking
as
well,
that's
a
perfect
venue
to
have
a
whole
day
of
talks
about
divinity
cool.
That's
it.
C
Yeah
I
was
just
wondering:
I
I
didn't
see
node.js
as
like
a
specific
column
on
there.
So
I
was
just
wondering
if
that's.
A
Do
you
want
to
answer
a
fact?
I
I
I
can
comment
on
on
TCP
and
quick,
so
TCP
Works
in
node.js.
They
have
been
working
on
quick
support
for
the
longest
time,
but
as
far
as
I
know
it's
not
merged
yet,
so
you
can't
do
you
can't
do
quick,
which
also
means
you
can't
do.
Web
transport
I
think
there's
websocket
support,
I'm,
not
sure
about
webrtc.
We.
B
Did
support
some
of
this
or
we
are
supporting
a
lot
of
this
from
from
the
JS
side
from
the
browser
so
right
and
the
node.js
side,
but
either
we
depend
on
Central
stun
and
turn
servers,
or
we
depend
on
the
fact
that
we
previously
established
a
websocket
connection
to
that
peer.
B
Now,
if
we
depend
on
Central
Standard
turn
service,
that's
a
bummer
right.
It's
called
Liberty
and
not
lipid
V,
plus
some
Central
servers
and
then
the
second
one
is,
if
the
the
second
one
where
you
already
have
an
established
connection
over
web
sockets
and
then
as
exchange
the
sdp,
you
might
as
well
just
use
the
yes,
the
websocket
connection.
Maybe
you
get
more
performance
of
the
website
connection
but
yeah.
E
Hey
you,
you
had
a
slide
about
punching
holes
in
the
browsers,
yeah
and
I
mean
it
definitely
sounds
really
technical
technically
pretty
exciting,
but
is
that
morally
wrong
thing
to
do
morally
wrong?
Yeah
like
because
it
seems
like
you're
going
over
some
sort
of
like
a
isolation
or
firewall
which
protects
the
browser
or
protects
a
user?
And
if
you're,
going
If,
you're
sort
of
like
bypassing
that
that
could
lead
to
disastrous
consequences?
Okay,.
B
Got
it
all
right,
I
wasn't
prepared
for
this,
but
let
me
let
me
see:
okay,
so,
first
off
we're
not
inventing
hole
punching
for
the
browser
that
already
exists
in
every
single
browser
out
there.
So
if
an
hacker
wants
to
make
your
node
your
browser
right
now
available,
if
you
use
one
of
the
major
browsers
and
you
download
their
JavaScript
codes,
that's
already
possible
today,
we're
just
making
use
of
it
now,
whether
that's
ethically
concerning
I,
would
say
no,
but
you
might
draw
the
line
somewhere
else.
Yeah.
A
So
I
would
argue
that
it's
that
it's
not
not
an
ethical
concern
in
any
way,
because
the
the
firewall
already
allows
you
to
dial
connections
from
your
node
to
other
nodes
right.
A
So
so
the
only
thing
that
hole
punching
enables
you
to
do
is
now
dial
a
connection
from
your
node
to
another
node,
who
also
happens
to
be
behind
the
firewall,
but
I
don't
see
that
there's
like
a
like
a
categorical
difference
between
dialing
a
server,
that's
on
the
public,
internet
and
dialing
a
server.
That's
that
happens
to
be
behind
the
firewall
I.
B
D
G
You
mentioned
that
all
the
PTP
connections
are
encrypted
like
there's
no
such
thing
as
a
non-encrypted
one
could
could
you
allow
for
like
the
non-encrypted
version
like
if
we're
building
a
protocol
on
top
of
it,
it's
got
its
own
security
properties.
We
might
be
able
to
squeeze
some
performance
by
not
having
that
as
a
default.
A
So
the
problem
with
unencrypted
connections
is
that
there
are
a
lot
of
like
you're
running
application
protocols.
On
top
of
that
connection,
and
you
run
it
like
w2p
is
also
running
some
coordination
protocols
on,
on
top
of
the
on
the
same
connection,
so
you
would
want
to
have.
You
would
want
to
have
encryption
for
for
at
least
the
lipid2p
protocols,
and
you
probably
also
want
to
verify
the
peers
identity
depending
on
on
your
application
protocol.
A
B
B
D
That's
that's!
Yes!
It's
working,
so
my
question
was
it's
possible
to
do
TCP
and
quick
over
to
lipit
to
be
on
top
of
CCP
and
quick?
What
about
raw
UDP
foreign.
A
There
was
an
effort
to
add
raw
UDP
support
to
browsers
I
think
they
started
about
around
10
years
ago,
and
there
was
a
lot
of
discussion
on
that
and
then
it
died
down
because
people
just
couldn't
figure
out
the
security
properties
of
allowing
a
browser
to
send
raw
UDP
packets.
So
that's
that
that
effort
has
basically
died
and
it's
probably
not
coming
back.
B
D
B
Because
I
think
we
have
many
use
cases,
why
not
to
support
the
ADP
and,
as
Martin
just
said
like
most
of
those
are
security
related
and
then
many
more
from
the
usability
perspective
yeah
so,
for
example,
I
think
your
number
one
example
is:
how
do
you
stop
a
replay
attack?
How
do
we
do
condition
control?
How
do
you
have
this
on
a
live
Network
where
everyone
can
pump
as
many
UDP
packets
into
the
socket
as
they
want?
How
do
we
do
that?