►
Description
This talk was given at IPFS Camp 2022 in Lisbon, Portugal.
A
All
right
so
then
I'll
go
on
with
the
transition.
So,
as
you
may
know,
like
migrating,
a
DHC
on
live
network
is
quite
challenging,
and
that
is
because
so
what
happens
now
is
when
I
make
a
DHT
lookup
request.
I
will
find
the
right
node
in
my
routing
table
and
send
them
the
request
and
the
request
will
in
the
request,
I
will
say:
Okay
I
want
this
CID
and
what
the
node
will
do
is
we'll
take
this
CID
hash
it
and
then
look
inside
their
routing
table.
A
What's
the
closest
Spear
and
give
it
back
to
me
and
now,
with
the
the
upgrade
I,
send
them
directly
the
hash,
so
they
don't
have
to
Hash
my
input
anymore.
They
can
directly
look
in
the
into
their
routing
table,
so
it's
cheaper
for
them
it's
good,
but
it
means
that
they
have
to
know
if
it's
a
private
request
or,
let's
say
a
legacy,
normal
request,
and
so
the
the
nodes
that
are
already
running
and
that
are
not
updating,
do
not
support
this
kind
of
requests.
A
Yet
so
it
means
that
we
need
a
migration,
and
so
that's
interesting.
So
what
we
could
do
is
we
could
start
a
new
DHT,
which
means
that
we
keep
the
old
DHD
we
put
up
a
new
DHT
and
so
each
sleepy
to
P
node
would
so
the
newly
P2P
node,
let's
say
from
the
next
version
where
it's
implemented
are
part
of
both
BHT.
So
it
means
that
they
will
publish
content
in
both
DHT
in
the
private
way
and
in
the
non-private
way,
and
they
will
look
up
for
content
in
both
dhts.
A
But
it's
not
that
good,
because
currently
we
are
running
so
in
implementation
for
dhts
one
client
Lan,
one
server
Lan
and
the
same
client
and
server
for
the
wide
area
network.
So
it
means
that
we'll
need
to
get
to
eight
dhds
and
so
to
the
the
state
of
the
routing
table
would
just
like
double
and
yeah.
It's
not
it's
not
really
desired,
and
it
also
means
that
for
the
next
upgrade,
we'll
need
to
just
create
four
more
dfts
and
four
more
DHT.
A
So
what
we
could
do,
a
better
solution
could
be
to
have
an
upgradable
DHT,
which
means
that
we
have
one
network
where
all
of
the
peers
are
connected
together,
but
it
would
support
a
multiple
type
of
requests.
So
how
can
this
work
so
each
node
needs
to
now
to
keep
track
of
the
versions
like
the
protocol
version
of
all
of
the
other
nodes
in
its
routing
table,
and
what
we
want
to
do
is
we
want
to
prefer
the
nodes
that
are
running
the
same
protocol
version
as
us,
so,
for
instance,
if
I'm
running
the
new.
A
A
A
Because
all
of
the
node
support
I
mean
the
newer
nodes,
support
both
kind
of
requests
and
I'm
more
likely
to
be
able
to
make
a
new
request,
because
I
know
more
peers
that
support
these
new
requests.
So
what
will
change
so?
The
key
bucket
with
a
high
ID,
which
is
the
node
that
are
close
to
me
in
the
small
bucket,
will
not
change
because
there
are
no
better
candidates
or
there
are
not
a
lot
of
candidates
in
this
bucket.
So
the
peers
will
not
be
affected,
but
the
buckets
are
far
away
from
me.
A
So
the
buckets
with
the
low
ID
are
going
to
have
a
lot
of
candidates,
and
so
it
means
that
I
can
just
cherry
pick
the
one
that
I
want,
so
the
the
newer
one
that
support
the
private
retrieval,
and
so,
if
we
make
now
an
analogy
so
forget
about
like
the
the
Academia
Source
base
and
so
on,
you
can
close
your
eyes.
If
you
want
we're.
If
you
want
to
find
some
location
in
the
real
world,
so
let's
say
yeah
a
GPS
coordinate.
A
A
That
has
a
road
because
you
want
to
stay
on
the
road,
and
so
you
will
do
this
this
analogy,
and
now
we
can
suppose
that
the
new
private
request
so
going
there
by
car,
isn't
private,
because
people
can
follow
you
and
know
the
stuff
you're
looking
at.
But
now
we
can
imagine
that
you
get
there
by
train,
but
so
you
need
to
have
a
trained
Network.
So
when
you
go,
you
decide
either
to
do
the
private
request.
A
So
you
get
on
the
train
and
get
there
by
train
or
you
go
on
your
car
and
you
do
the
normal
request,
and
so
it
works,
but
the
at
the
beginning,
the
train
network
will
be,
let's
say,
less
developed,
which
means
that
the
closest
location
to
your
to
the
exact
location
you
want
to
go
has
to
be
a
train
station.
So
it's
probably
going
to
be
more
far
away
than
if
you
are
with
a
car.
A
A
But
now
it
means
that
we
have
to
maintain
two
different
networks
right.
We
have
to
maintain
the
roads
and
the
rails,
and
so
that's
the
2D
HD.
But
what
if
we
could
just
take
our
existing
roads
and
add
some
rails
there
right?
So
we
would
have
some
trams
that
would
run
on
the
road.
So
we
have,
we
will
still
need
to
hit
like
one
single
infrastructure,
but
that
can
do
everything.
A
And
so
that's
like
the
the
analogy
where
you
keep
the
same
peers.
So
you
keep
the
same
road,
but
you
just
upgrade
them
and
you're
gonna
drop
the
the
old
roads
that
don't
don't
have
rails,
and
so
that's
what
I
call
the
DHT
Tran
upgrade,
because
we
want
to
add
rails
on
the
road
and
let's
make
the
interplanetary
route
upgradable
so
that
we
can
have
I
need
to
planetary,
monorails
or
a
road.
Our
road
can
support
like
rockets
in
the
future,
so
we
can
upgrade
our
DHT
according
to
to
the
requests.
A
So
now
the
the
RPC
that
we
have-
and
so
we
will
want
in
new
rpcs
so
for
private,
provide
and
private
lookup
when
you
so
yeah.
Basically,
when
you
will
provide
some
content,
you'll
just
take
the
train,
go
to
the
closest
train
station
and
put
your
pointer
there
and
anyone
that
wants
to
get
it
by
the
train
will
just
take
the
train
as
well
and
go
to
the
same
place
where
you
left
it,
and
so
that's
for
the
train.
But
then
the
find
Pier
wouldn't
change.
A
So
it's
still
the
road
because
the
regional
roads
around
you.
We
have
to
keep
them.
We
have
to
be
very
precise
when
we
find
peer,
which
is
not
the
case
for
fine
content,
so
we
will
keep
the
existing
infrastructure
for
the
fine
prpc,
and
so
the
older
current
provide
and
look
up.
I
will
still
be
accessible
because
we
can
still
drive
on
the
road
now
I'm,
just
some
load
calculation.
So
what
we
expect
is
a
not
much
more
load
to
be
on
the
new
DHC.
A
So
now
the
current
load
is
We
have
basically
for
each
node.
We
have
all
of
the
requests
and
divided
by
the
peer
number
and
that's
the
expected
load.
But
now,
if
some
of
the
load
goes
to
the
private,
like
the
private
request,
then
the
Legacy
note
would
have
less
traffic.
So
like
the
same
request,
minus
the
private
request
and
the
upgraded
peers
will
still
have
the
let's
say,
the
the
load
for
the
old
request,
plus
the
load
for
the
new
private
request.
A
But
this
is
expected
to
be
very
bounded,
because
we
expect
that
the
number
of
private
requests
will
grow
with
the
number
of
private
peers,
which
would
be
scalable
and
so
yeah
to
just
a
small
remark
is
so
if
we
do
this,
let's
say
tray,
train
and
car
analogy
at
some
point.
We
may
want
to
just
drop
the
road
and
have
rails
only
because
it's
better,
but
it
will
just
break
the
old
node
because
they
cannot
get
anywhere
anymore.
A
So
what
we
want
to
do
is
that
the
the
newer
version
prefer
to
be
connected
with
the
newer
version,
and
the
older
version
are
connected
with
the
older
version
so
that
if
they
want
to
still
do
their
their
own
DHT
fairy
Legacy,
they
can
do
it.
They
can
stay
on
their
Road,
even
if
the
rest
of
the
network
has
moved
on
and
so
that
already
works
for
the
newer
node.
So
young
prefer
young,
but
all
prefer
old.
A
A
But
if
the
provider
content
didn't
publish
it
there,
then
you
may
want
to
failover
to
do
a
legacy
lookup
and
then,
after
some
adoption,
the
content
provider
will
just
stop
publishing
to
the
old
DHT,
and
maybe
at
some
point,
so
it
still
has
to
be
decided
if
we
want
to
break
the
old
nodes
to
force
them
to
upgrade
or
if
we
just
allow
them
to
keep
their
old
DHT.
We
may
stop
supporting
the
Legacy
content
request
and
yeah.
That's
called
out
for
breaking
DHT
protocol
changes.
A
So
if
you
plan
on
Breaking
the
DHC
I
think
so,
even
if
the
DHC
is
upgradable,
we
should
minimize
the
number
of
protocol
versions.
So
please,
let
me
know
if
you
plan
to
break
something
so
that
we
can
group
the
changes
and
make
only
like
break
it
once
and
so
to
conclude,
so
this
double
hashing
DHT
brings
a
significant
reader
privacy
Improvement,
but
it's
not
perfect,
as
we've
seen
it.
A
It
also
brings
provider
record
authentication
like
stronger
than
what
we
have
today
and
we
also
have
in
bonus
a
small
writer
privacy
Improvement
in
the
DHT.
We
have
a
lower
head
as
we've
seen
and
it
is
interoperable
with
other
content.
Router
such
as
the
indexer
at
the
implementation
of
the
DHC
is
almost
over.
We
still
need
to
test
and
still
need
to
yeah
make
a
make
the
decision
for
the
for
the
upgrade
and
make
a
more
precise
roadmap.