►
From YouTube: Q3+ updates in Discovery, Routing and IPNS - IPFS GUI and In Web Browsers Weekly, 2019-07-24
Description
About this call: https://github.com/ipfs/team-mgmt/issues/790
IPFS Mirror: https://ipfs.io/ipfs/bafybeiagjupenwsqqjno6556zlchptlfxez6x7w2kyy4lpuwtrkmmmpayq
B
B
A
So
only
it
was
not
able
to
join
us
today,
but
I
can
give
a
short
summary
of
where
we
are
so.
Basically
the
problem
was
we
were
loading
web
UI
from
the
Gateway
port
to
deliver.
The
latest
version
to
activist
companion,
users
and
the
problem
that
came
with
loading
from
the
gateway
port
was
that
the
gateway
port
and
API
port
have
different
origins,
so
you
had
to
deal
with
cross
origin
security
and
companion
just
lifted
lifted
off.
That.
A
A
We
wanted
to
also
allow
people
to
load
the
latest
version
using
DNS
link
on
web
UI,
dot
ipfs
io,
but
that
one
sort
of
introduced
potential
security
problem
when
we
have
when
we
have
a
person
in
a
cafe
and
that
there's
a
malicious
DNS
server.
Returning
a
different
DNS
link
right
now
go
idea.
Files
and
jessup
EFS
are
using
DNS
resolvers
provided
by
the
operating
system
and
there's
no
way
to
tell
if
that
DNS
query
went
over
encrypted,
like
DNS
over
TLS
DNS
over
HTTP
or
maybe
plaintext,
and
usually
it's
just
the
NS
over
plaintext.
A
So
above
people
can
look
what
you
querying
and
as
well.
They
can
provide
a
rogue
DNS
server
that
introduces
a
different
response
and
that
way
make
your
go.
Ideas
provide
you
with
different
web
UI,
so
the
plan
for
that
is
to
put
brakes
on
those
PRS
for
loading
web
UI
from
IP
ans
from
using
DNS
link
and
until
we
have
a
support
for
DNA
like
encrypted
the.
So
the
minimum
thing
we
need
is
to
ensure
go.
A
A
Recursive
resolver
similar
something
similar
like
DNS
over
HTTP
feature
in
Firefox
I,
believe
that's
more
or
less
the
story
on
my
end
I'll
ship
that
first
patch,
which
falls
back
to
the
web
UI
provided
by
go
ipfs
with
the
next
activist,
companion,
better
release
and
the
PR
that
enabled
enables
people
to
opt
into
the
IP
Ana's
is
also
ready
to
merge
the
way
I
made.
It
is
eat
the
text.
It
detects
that
the
IP
NS
path
is
not
supported
and
falls
back
to
the
old
one.
A
B
Can
you
can
you
explain
what
what
we
get
from
these
changes
and
also
that,
even
once
you
solve
the
do,
H
like
you,
let's
say
you
solve
the
unencrypted
DNS
problem
to
ensure
that
it
is
encrypted.
Do
we
still
have
compatibility
problems
if
there's
other
IPS
nodes
running
that
aren't
new
we're?
Maybe
in
don't
support
this?
Is
there
a
compatibility,
backward
compatibility,
fallback,
mmhmm.
A
A
That
problem
with
the
problem
with
DNS
is
that
right
now
we
just
assumed
when
we
do
DNS
linked
lookup.
We
just
assume
it's
it's
valid.
The
truth
is
that
most
of
people
use
unencrypted
DNS
server
provided
by
their
ISPs.
So
it's
not
like
there's
a
compatibility
problem
for
the
go.
Igfs
is
just
a
peg.
It
does
not
know
who
resolved
that
it
just
asked
operating
system
for
name
for
IP,
for
that
name
or
txt
record
and
gets
it.
So
that's
like
well.
A
A
B
A
So
like
on
the
companion
site,
it's
mostly
about
removing
the
maintenance
burden.
It's
like.
We
remove
the
code
that
was
responsible
for
all
the
orchestration,
but
for
regular
users
total
it
improves
security,
especially
if
we
add
like
hardened
DNS
to
both
go
and
J's
that
will
totally
put
a
veil
of
secrecy
on
what
the
enhancing
websites
you
are
visiting.
Basically,
I.
B
A
A
For
those
new
solutions
such
like,
such
less
like
rendezvous
protocol
and
the
really
protocol,
so
it's
just
to
put
it
on
the
map,
and
that's
that
will
the
start.
Protocols
are
solving
content
and
peer
discovery
right
now.
So
that's
why
it's
under
this
topic-
and
the
second
leg
under
this
topic
is
how
we
can
improve
delegated
through
thinking
web
browser.
So
delegated
routing
is
one
of
solutions
to
replace
start
protocols.
A
The
way
it
works.
Is
you
delegate
some
queries,
such
as
like
asking
PhD
for
peers
that
have
this
CID
or
maybe
profile,
publishing
a
record
that
you
can
provide
this
specific
cid
to
people
if
they
want
to
so
delegated
routing?
We
have
like
a
modules
for
delegated
routing
for
content
and
Spears,
and
the
problem
or
challenge
is
that
it
needs
to
be.
It
will
be
mostly
used
in
web
browser
and
web
browsers
come
with
some
challenges.
A
The
way
delegated
routing
works
is
basically,
you
specify
a
list
of
web
service
endpoints
that
your
JS
ipfs
node
will
get
when
you
delegate
some
commands
and
the
way
web
browsers
handle
requests
to
remote
origins
is
that
you
have
a
limit
of
I.
Think
I
believe
it's
like
six
concurrent
connections
per
host
and
also
we
have
some
commands,
such
as
preload,
like
recursive
preload
of
a
big
data
set,
may
take
some
time,
which
means
that
one
request
will
hang
for
a
long,
long,
long
time
taking
one
of
those
six
slots.
A
So
it's
like
ongoing
challenge
to
tweak
delegated
to
routing
modules,
to
work
better
in
web
browser.
One
way
is
to
throttle
the
number
of
concurrent
requests,
I
believe
those
PR
already
landed.
The
next
step
is
to
support
like
timeouts
for
those
long-running
requests,
because,
like
in
web
browser
context,
we
will,
if
we
hit
like
more
than
5
6
preload
requests
that
take
too
much
time.
A
As
a
like
in
the
illustration
that
it's
like
an
ongoing
effort,
we
need
to
land
those
new
solutions,
make
sure
those
solutions,
work,
there's
like
a
default
public
infrastructure
and
instructions
for
other
people
to
run
their
own,
either
delegated
routing
nodes
or
like
relays,
and
then
at
some
time
we
will
switch
from
start
protocols,
I
believe
that's
more
or
less
the
story
behind
that.
If
anyone
is
interested,
there's
more
in
there,
I
have.
B
A
question:
do
we
have
an
understanding
of
kind
of
what
the
performance
ceiling
will
be
able
to
get
out
of
this
like
if
we,
if
I,
think
that
the
WebRTC
basics
connection
cap
was
actually
or
increased
to
20,
or
something
like
that
and
some
browsers?
But
do
we
have
an
understanding
of
how
close
these
types
of
optimizations
like
adding,
timeouts
and
throttling
concurrent
requests
will
get
us
because
it
seems
like
the
nature
of
those
kind
of
reduces
the
amount
of
overall
network,
throughput
or
activity
that
is
available
at
a
given
time?
B
A
For
for
the
short
term,
totally
that
will
be
the
fastest
thing.
It's
like
more
sort
of
like
a
preload
on
steroids
and
that's
just
like
regular
HTTP
requests.
So
it
does
not
like
use,
WebRTC
or
or
and
think
it
just
delegates
API
to
some
our
remote,
a
HTTP
API.
So
that's
like
a
short-term
fix,
so
people
can
run
their
own
delegated
Reuters.
A
A
It
will
be
provided
through
the
network
using
delegated
node,
which
means
all
nodes
that
were
not
able
to
reach
you
before,
because
you
were
running
in
web
browser
and
you
were
not
opening
ports.
Those
nodes
now
will
be
able
to
reach
and
fetch
that
content,
because
the
way
delegated
content
routing
works.
When
you
execute
like
the
provide
method,
it
will
ask
the
delegate
node
to
fetch
that
data
from
you
and
then
publish
it
to,
and
it
will
automatically
publish
it
to
the
HT
that
it's
providing
into
the
network.
A
B
Again,
it
sorry
they
notice
they
couldn't
reach
you,
because
you're
running
a
browser
before
they're
able
to
get
that
wanted
that
content.
So
somehow
they
got
access
to
that
cid
on
the
band's.
They
asked
for
that's
the
ID.
They
can
get
it
from
the
delegated
nodes
that
you
asked
to
hold
that
for
you,
yep
yep
and,
like
a
almost
seems
like
a
a
vaguely,
pinning
ish
yeah.
C
A
It's
like
you,
ask
that
node
to
fetch
the
content
from
you,
because
you
have
delegated
node
in
your
boot,
strap
node,
so
you
are
always
connected
to
it.
So
that
note
is
able
to
fetch
the
content
from
you
and
then
it's
placed
in
the
cash
in
the
ripple.
Repo
of
that
note.
So
until
the
garbage
collection
cycle
hits
that
data
is
provided
from
that
node.
So
that's
like
a
good
solves
the
problem
of
when
you
are
sharing
stuff
from
when
one
wave
up
to
another
web
app.
A
A
Yeah,
it's
like
when
you
share
something.
Can
you
close
your
laptop?
You
still
want
this
person
who
you
send
like
a
link
or
something
to
be
able
to
reach
the
data.
That's
like
a
short-term
delegated
routing
and
for
a
longer
term.
That
will
be
like
a
really
protocol
and
and
rendezvous,
which
means
people
will
be
able
to
chew
gum.
A
So
that
that's
when
we
preload
kicks
in
so
you
bet
you
ask
when
you
get
those
peers,
you
can
ask
the
delegate
to
also
pull
up
that
content
on
itself
and
then
you
are
already
connected
to
the
delegate.
So
you
can
fetch
data
from
the
delegate.
I
believe
there's
like
a
small
window
that
we
don't
address
yet
using
delegated
modules.
I
think
that
that's
related
to
fetching
remote
data
when
I
ask
something
from
great
way,
not
sure
how
to
how
specifically
we
want
to
go
in
there.
A
E
A
So
it's
like
the
delegated
routing
is
just
like,
like
simple
solutions
for
now
until
we
have
like
a
proper
realized,
because
the
way
delegate
works,
it's
very
naive.
It
just
like
prefetches
specific
block,
and
we
assume
it
that
the
block
will
be
there
for
some
time
either
for
someone
else
to
fetch
or
for
asked
to
fetch
from
this
node
immediately.
A
Something
that's
more
advanced
is
a
mixture
of
rendezvous
and
relays.
When
we
get
more
distributed
protocol
of
peers
meeting
at
some
remote
rendezvous
point
and
then
realizing
they
both
can
talk
WebRTC,
for
example,
and
then
they
could
upgrade
the
connection
and
talk
directly,
but
until
we
have
that
that
that's
why
we
need
delegated
routing
first,
okay,.
C
A
The
if
we,
if
true
like
the
delegated
Peru,
think
we
get
notified
about
this
Pierre
has
the
block
you
want
and
that
Pierre
has
like
WebSocket
address,
there's
no
problem.
We
can
directly
connect
to
it.
The
problem
is
that
WebSockets
like
web
browser
node,
is
not
able
to
open
web
sockets
like
for
listening.
We
can
just
like
establish
outgoing
ones.
So
if
there's
like
a
go,
ipfs
node,
exposing
WebSocket
transports,
we
can
connect
to
that
yeah.
But
that's
what
I'm
saying
so
you
use.
A
Can
do
right
now,
oh
yeah,
totally
and
I.
The
problem
is
I've
been
looking
at
that
as
part
of
the
work
I'm
doing
and
brave,
and
the
problem
is
that
there
is
not
not
that
many
peers
listening
on
WebSockets,
because
that
requires
either
requires
setting
up
certificate
and
using
like
manually
configuring,
a
WebSocket
transport
in
go
ipfs
or
someone
just
enabled
unencrypted
web
socket
and
that's
a
problem,
because
if
you
are
running
JS
ipfs
on
the
https,
you
are
not
able.
C
A
D
A
People
could
run
their
own
so
that
could
be
or
should
be,
like
a
linked
package.
So
you
both
expose
web
web
sockets
on
the
certificate
to
the
network.
You
act
as
out
to
relay
and
if
more
and
more
people
are
institutions
run
those
that
will
totally
improve
the
health
of
the
network
and
especially
if
you
are
running
Jessica
facing
web
browser,
that
that
note
would
be
able
to
connect
to
more
peers.
But
I,
don't
think
that's
a
realistic
to
expect
that
will
solve
the
problem.
We
will
need
still
the
outer
relays.
A
B
B
A
Because
we
right
now,
people
are
using
WebSockets
star
for
the
things
that
those
things
will
provide,
but
we
cannot
expect
people
to
run
their
own
right
now.
People
usually
when
they
start
playing
with
ideas
or
p2p.
They
use
signaling
WebSockets,
start
signaling
from
the
readme
that
we
provide
for
the
community
to
experiment
and
play
with
so
at
least
we
should
we
to
start
experimenting
with
this.
E
D
B
A
So
the
problem
we
had
with
realized
before
was
those
relays
were
used
for
actually
pushing
the
data.
All
the
data
had
to
went
through
those
relays
and
we
started
it
as
an
experiment,
and
there
were
no
other
relays
on
the
network
and
finding
them
is
expensive
when
it
comes
to
bandwidth,
because,
like
actual
data
goes
through
those
relays,
the
plan
to
mitigate
that
is
to
both
run
those
relays
but
give
additional
protocol
for
nodes
to
upgrade
to
peer-to-peer
connection.
A
So,
for
example,
when
I
have
to
know
jaesik
FS
nodes
running
in
a
web
browser
by
default,
though
those
both
nodes
are
not
able
to
talk
to
each
other,
they
will
talk
to
each
other
through
some
relay.
However,
once
those
nodes
are
able
to
talk
to
each
other,
they
can
realize
hey.
We
both
can
talk
WebRTC.
A
So
at
that
point
those
those
nodes
can
upgrade
the
related
connection
to
the
peer-to-peer
one
and
that
would
save
the
bandwidth
for
relays,
because
those
peers
would
just
use
relays
for
like
a
rendezvous
point.
There's
a
when
we
talk
about
this.
There
is
like
often
like
a
mixing
of
rendezvous
and
relay
because
sometimes
as
single
machine
single
node
can
act
as
both.
C
You
I
got
a
quick
question
about
the
rendezvous,
so
are
there
plans
to
be
able
to
make
that
happen
through
browser
nodes
as
well?
So,
for
example,
you
know
I'm
connected
to
a
pier
that
this
other
person's
not
connected
to
we're
communicating
through
WebRTC,
can
I
help
them
connect
with
this
other
person.
B
B
D
Everything
like
to
correctly
deploy
the
name
servers
and
all
that
stuff
and
that's
the
work
that
needs
to
be
to
happen.
This
quarter
plus
a
couple
of
at
least
on
share
side
a
couple
of
tweaks
and
that
the
cold
still
needs
like
the
one
we
were.
We
were
talking
about
supporting
DNS
over
HTTP
of
a
debt
and
one
other
thing
which
is
adding
some
or
for
this
on
the
go
side
is
also
tech
tips
for
this
quarter.
D
Dominic
is
already
has
already
a
preliminary
implementation
of
the
Robert
that
Miss
rural
over
DNS,
but
it's
still
in
early
stages,
and
we
need
to
still
make
its
lands
in
in
the
wacky
effects,
and
right
now
me
and
Nadine
were
we're
talking
about
extracting
happiness
completely
out
of
a
BFS
in
go
and
Jess.
Some
guys
from
the
thirteen
need
this
to
be
able
to
kind
of
in
some
of
the
service.
D
D
D
B
D
A
D
A
B
Have
a
question:
I
am
curious
once
this
set
of
changes
lands.
What
is
that
landscape?
Look
like
for
people
using
this?
Is
this
primarily
a
performance
benefit?
What
do
we
get
besides?
I
know
from
the
previous
discussion.
We
get
a
lot
of
local
and
that
privacy
from
moving
to
this,
and
it
sounds
like
we
also
get
a
lower,
also
some
lower
maintenance
burden,
because
communication
and
resolution
will
be
using
maybe
a
more
unified
approach.
But
what
else
do
we
get
out
of
these
changes?
B
D
Think
you
basically
everything
well,
we
we
get
in
one
single
router
support
for
like
global
use
over
the
internet
and
we
get
privacy
with
DNS
overage
CVS.
We
don't
use
any
of
the
current,
like
DHT
network,
to
do
anything
with
this
role,
so
it's
kinda
not
as
much
as
a
centralized
scan
as
the
HD,
but
it's
like
streamline
everything
is
already
known
by
everyone,
because
you
ness
is
an
all
tech
yeah.
It's
it's
super
fast.
D
D
B
B
Yeah
I
have
a
follow-up
question
to
that
question,
which
is
you
said:
there's
a
the
users
now
are
making
a
choice
between
the
fast
option,
be
fast,
centralized
option
or
the
decentralized
option
do
we
have
plans
to
make
that
a
little
bit
more
dynamic
so
instead
of
a
binary
either/or,
a
choice
that
will
be
dynamically
fallback.
So
if
you
choose
the
fast
centralized
option
and
that
fails
due
to
state
state
actors
may
be
walking
certain
xena,
then
it
would
fall
back
to
this
lower
decentralized
option.
D
Yeah
we
have
a
plan
to
out
to
all
twine
the
lids
right
now.
I,
don't
think
we
will
implement
it
completely.
We
will
define
a
single
strategy
to
publish
and
result,
but
the
plan
is
to
add
more
options
and
like
a
callback
thing
that
you
get
that
user,
the
user
gets
to
receive
the
other
responses
that
come
from
different
routers.
D
E
C
C
We've
actually
got
the
text
description.
Well,
it's
a
mix
right.
You
have
a
lot
of
unknowns
here
and
then
you
have
somewhere
it's
a
city
in
a
country,
so
they
were
wanting
to
sort
by
a
fixed
location,
sorting
but
I'm
curious
about
like
what
you
guys
think
logically
works
for
sorting
location
names.
Would
it
be
sorting
by
the
country
and
then
so
country
and
then
city,
so
you'd
see
the
cities
alphabetically,
but
in
order
of
countries
or
yeah
I'm
trying
to
figure
out
what
makes
the
most
sense
there.
If.
E
So
if
you
were
doing
it
by
basically
place
names,
then
I
do
think
country
and
then
said
he
would
make
sense.
It
would
make
more
sense
if
we
listed
it
as
United
States
Fairfield
than
if
we
listed
it
as
Fairfield
United
States,
but
that
doesn't
make
sense
to
me.
The
other
thing
we
talked
about
on
an
earlier
call
is
that
it
would
be
more
interesting
for
us
to
see
the
highest
latency
like,
which
might
be.