►
From YouTube: 2023-01-10 IPFS Content Routing WG #3
Description
IPFS Content Routing workgroup #3
Sync of those involved with creating IPFS Content Routing proposals:
Notes:
https://www.notion.so/pl-strflt/2023-01-10-Content-Routing-WG-3-991d6b01628b4b89b2debd16b5337d5e
more on the IPFS Implementers Sync including calendar information see:
https://www.notion.so/pl-strflt/Content-Routing-Workgroup-e59fa94a9c3f48d58480b7daf15bd356
Luma meeting series:
https://lu.ma/ipfs-routing-wg
Website: https://ipfs.io/
Twitter: https://twitter.com/IPFS
A
All
right
looks
like
I
shared
the
link
to
the
meeting
minutes,
so
I'll
go
ahead
and
share
my
screen:
I'm
working
off
just
a
laptop
screen
right
now.
So
if
any
of
y'all
have
any
chat
questions,
please
jump
in
and
just
mention
that
you're
looking
to
have
a
question
answered
because
I
will
not
be
able
to
see
it,
but.
A
All
right,
y'all,
so
I
dropped
the
meeting
minutes
in
the
chat
you
can
grab
them
and
follow
along
there
and
at
the
top
here
are
kind
of
some
of
the
current
specifications.
We're
working
on
for
folks
that
haven't
been
in
this
meeting
before
and
important
documents
that
outline
kind
of
some
of
the
technical
details
for
design
that
we're
presently
working
on.
A
You
can
go
ahead
and
drop
in
and
give
those
a
read
on
your
own
time,
but
these
are
pretty
important
docs
to
kind
of
keep
up
with
where
we're
at
with
the
content,
routing
work
group
and
then
the
purpose
of
this
meeting
is
basically
to
agree
on
a
technical
implementation.
Presently
of
double
hashing
is
actually
going
to
be
discussed
at
the
on-site.
Presently,
that's
been
the
scope
of
these
meetings
over
the
last
three
meetings,
but
we
do
have
kind
of
aspects
of
double
hashing
and
the
outcomes.
A
So
we'll
start
off
with
the
discussion
of
just
a
handful
of
topics
that
we
have
here:
it's
not
quite
as
voluminous
as
it
usually
is,
so
we
actually
might
be
able
to
compact
this
meeting
but
I'll.
Let
you
all
dictate
whether
or
not
we
are
able
to
cover
everything
in
the
time
that
we
have
available
since
the
HTTP
delegated
content.
Routing
discussions
are
going
to
be
happening
on
site.
The
primary
topic
that
we
wanted
to
cover
today
was
the
bifrost
implementation.
A
I
think
we
found
out
somewhat
over
break
but
kind
of,
as
we
ramped
back
up
that
it
sounds
like
the
deployment
range
of
versions
is
a
little
bit
different
than
I.
Think,
possibly
what
we
knew-
or
maybe
people
did
know
that,
but
the
important
output
outcome
is
that
we
need
to
kind
of
align
on
the
deployment
and
versions
and
basically
reach
a
unification
of
everything
to
version
17
with
ultimately
version
18
being
the
the
outcome
goal.
A
A
B
B
B
C
D
C
D
B
Actually
I
mean
to
be
complete
to
be
completely
Fair.
Well,
first
of
all,
that's
a
reason.
That's
a
that's
a
reason
why
we
are
doing
it
on
a
test
setup
machines
before
actually
deploying
it
everywhere,
and
the
quote-unquote
nice
thing
about
doing
it
in
these
hosts
and
not
the
Nitro
clusters.
Is
that,
if
necessary,
you
can
just
wipe
everything,
because
there
is
no
real
production
data
anywhere
there
I
mean
the
gateways
are
just
basically
cash
right.
B
So
the
only
thing
that
will
happen
is
that
ttfb
will
suffer
for
a
time,
because
we
wipe
the
whole
thing.
We
have
at
some
point
had
to
wipe
the
whole
thing
and
yeah
it
shouldn't
be
that
much
of
a
problem
preloads
might
be
a
little
bit
if
he,
whether
to
do
not
I
mean
we
might
have
some
complaints
from
you,
some
some
users,
but
in
the
end,
this
part
of
the
infrastructure.
The
nice
thing
is
that
it's
all
I
mean
it's
all
deletable
without
losing
data.
B
E
A
B
Yeah
there's
yeah
there's
a
I
I
was
looking
at
the
at
the
previous
bullet,
saying
something
about
that.
The
hydras
have
been
turned
off
as
far
as
I
know,
part
of
the
Hydra
functionality
was
turned
on,
but
part
of
what
Hydra
functionality
is
still.
There
is
so
the
hydrants
are
not
there
anymore
to
to
support
the
DHT
to
you
know,
make
the
DHT
better,
but
the
functionality
to
serve
as
a
bridge
between
reframe
or
content
or
well.
Basically,
the
indexers
and
the
DHT
I
think
is
still
there.
I
think
something
like
that.
B
A
A
E
A
A
Okay,
cool
cool,
so
Mario.
Does
that
clarify
for
you
at
all
kind
of
the
the
current
operating
State?
Perfect,
that's
awesome!
Okay!
Does
anybody
else
have
any
clarifications
that
they
need
of
this
topic?
Regarding
the
bifrost,
we
call
it.
Maybe
remediation
plan
that
we're
undertaking
for
for
Mario
or
his
team
at
all.
D
B
A
B
B
B
I
am
assuming
that
Jeff
bumped
up
I
guess
some
problem
last
night
because
he
said
that
he
was
going
to
have
the
pr
ready
by
this
morning
for
me
to
review
and
he
did
not,
which
is
and
I
haven't
synced
with
him
today.
So
I
am
assuming
that
he
bumped
up
against
some
other
problem
and
I
really
don't
want
to
do
it
myself,
since
he
was
already
he's
already
working
on
it
and
I.
B
D
I
mean
so
so
here's
the
thing
right
like
we
started
asking
for
this
in
October
to
to
test
it
and
then,
a
month
ago
you
said
all
three
blanks
have
been
deployed.
What
fraction
was
that?
Because
that's
how
we've
been
trying
to
understand
how
much
traffic
we're
getting
from
gateways
and
it
sounds
like
we
only
got
a
fraction,
not
all
of
it,
but
we
don't
have
a
sense
of
like
how
much
we
got
what's
gone
now
and
how
much
we're
actually
going
to
get
when
this
eventually
does
happen.
B
Okay,
so
one
thing
I
mean
one
thing
we
can
do
is
I
would
have
to
check
exactly
because
we
that
was
the
other
thing
during
November
December
we
were.
We
were
running
multiple
experiments
at
the
same
time,
so
I'm
not
sure
which
one
is
which
in
one
of
them,
we
were
running
it
on
four
Banks,
so
I'm
not
completely
sure
which
one
it
was
right
now,
I,
don't
it
off
the
top
of
my
head?
A
C
I
have
one
question
which
I
think
sort
of
bridges
between
these
two
topics
on
the
delay
thing,
but
also
the
stuff
with
the
how
much
traffic
the
indexes
are
getting
yeah
the
indexes
are
gonna
double
up
on
traffic
from
gateways
right
because
they're
gonna
get
it
twice
once
from
the
hydras
and
then
once
from
the
given
that
the
hydros
are
effectively
an
attack
on
the
network.
That
is
anti-helpful.
C
C
C
D
C
A
D
B
B
Well,
actually,
one
thing
is:
it
will
probably
not
be
exactly
six
or
seven
times
because
we
are
using
on
the
load
balancers.
We
are
using
consistent
hashing,
which
means
that
which
node,
which
Kubo
node
a
request
sends
up
at
depends
on
the
hash
that
has
been
requested
at
that
point.
So
it
might
be
that
banks
that
those
banks
have
ended
up
in
a
hot
in
in
we
ended
up
with
hot
cids
or
with
cold
C
with
not
as
hot
cids.
A
B
A
D
D
Planning
thing
that,
but
right
it's
not
like
a
problem,
but
it
is
noting
that
if
we
get
rid
of
the
bit
swap
delay
to
dhts
or
indexers
we're
going
to
have
a
lot
more
reads.
We'd
like
to
understand
that,
as
it
gets
rolled
out
on
the
gateways
and
understand
what
that
read,
load
ends
up
looking
like
before
we,
you
know,
release
a
ipfs
18
with
the
thing
turned
off
right
like
that.
D
F
C
A
C
C
Through
a
directory,
oh
that's
going
to
hit
different
nodes
in
the
cluster
which
vet
swap
would
generally
fill
in
the
blanks,
but
each
of
those
navigation
nodes
will
now
result
in
a
new
DHT
and
indexer
request.
So
like
the
number
here
could
be
like
really
large.
If
we're
not
careful
in
the
magnification,
because
bit
swap
is
tapering
over
like
a
lot
of
stuff.
B
C
C
A
C
F
As
far
as
I
know,
it
hasn't
the
rerun,
but
so
the
the
setting
here
will
change
with
Kubo
0.18,
because
the
number
of
connected
peers
would
be
different.
So
we
would
be
interesting
to
run
this
experiment
again
internally,
though,
with
a
number
of
like
100
connected
peers
instead
of
800
and
compared
to
different
provider
search
delay,
so
1
500
and
once
again,
for
instance,
to
compare
the
performance
also,
we
couldn't
really
explain
the
result.
We
had
last
time
why
it
was
worse
with
a
zero
delay
and
yeah,
maybe
we'll
try.
C
C
C
F
C
A
So
for
anybody
that
wants
to
kind
of
follow,
along
with
the
state
of
progress
on
this
analysis,
that's
happening.
Is
there
anywhere
other
than
GitHub
right
now,
where
kind
of
these
tests
are
being
planned
or
communicated,
or
should
we
just
follow
along
in
the
GitHub
for
that,
and
we
can
use
this
discussion
forum
for
people
to
kind
of
be
updated
on
it?
A
Yeah,
it
would
be
good
if
we
could
incorporate
I,
wouldn't
say
like
a
gating
function,
but
it's
some
kind
of
like
testing
or
awareness
just
just
so
that,
and
and
maybe
this
meeting
the
content.
Rounding
work
group
is
a
good
way
just
to
kind
of
surface
when
those
Milestones
are
happening
so
that
we
can
prepare
and
plan
around
it
I
think
that
works
for
now.
A
E
C
A
A
D
F
E
D
Probably
right
now,
it's
cloudfront
is
the
caching
layer
and
that
costs
us
money.
I
mean
again.
This
is
also
sort
of
like
a
what's
the
current
state
of
the
world
versus.
Where
could
we
get
to
in
three
six
months?
If
we
manage
to
get
caches
onto,
for
instance,
the
Saturn
L
ones,
or
things
like
that,
we
could
manage
to
offload
a
lot
of
this
caching
with
at
lower
cost.
I.
F
Alternatively,
maybe
having
a
different
delay
for
the
indexers
and
for
the
DHT
could
do
the
trick
so
that
the
indexer
don't
get
extra
load
and
will
get
like
if
the
request
didn't
result
in
one
second
with
either
bit
swap
or
to
DST,
then
the
indexer
will
take
this
load,
so
the
load
doesn't
change
and
DHT
doesn't
need
to
wait
like
one
full.
Second,
and
this
doesn't
occur,
any
cost
as
the
hydras
are
now
down.
I
guess.
C
I'd
say
certainly
it's:
it
is
a
it's
a
a
bug
of
an
interface
bug
that
the
all
the
routing
systems
are
grouped
together
and
they
have
the
same
delay
penalty,
because
each
system
has
a
different
cost
yeah.
What
what
that
should
be
for
each
system?
I,
don't
know
yeah
I
think
like.
If
that's
the
thing
that
we
wanted,
that
we
were
like
yep,
it's
important
to
us
that
we
change
that,
because
we
want
it
to
be
a
shorter
delay
for
the
indexer.
Is
there
a
longer
delay
or
whatever
we
could?
We
could
do
that?
C
Probably
we
want.
Probably
it's
like.
If
the
shorter
you
want
to
make
it
or
the
more
you
want
to
eliminate
the
bits
while
papering
over
things,
the
more
you
have
to
start
fixing
other
stuff,
whether
that
means
Plumbing
sessions
properly
or
thinking
about
how
your
info
does
consistent,
hashing
or
whatever.
C
That
will
emerge
as
a
result
of
this,
and
hopefully
we
have
enough
metrics,
because
people
have
done
a
lot
of
metrics
work
in
the
last.
You
know
six
months
or
so,
but
we
might
need
more
yeah
just
because
it
would
I
mean
it's
good,
but
it
would
also
be
sad
if
the
way
that
we
were
collecting
metrics
on
way
too
many
lookups
was
Will,
calling
us
up
and
being
like
there's
a
lot
of
money
being
spent.
Can
you
figure
out
why
all
the
money
went
and
we're
like?
C
B
Speaking
speaking
of
money
spent,
since
we
have
so
many
smart
people
in
this
room,
perhaps
one
of
you
can
help
me
out
and
go
offline.
It
turns
out
that
I
mean
we
can
go
offline
and
and
figure
this
out,
but
it
turns
out
that
our
biggest
spend
in
equinix.
Our
biggest
line
item
is
outgoing
bandwidth
from
Kubo,
not
our
http.
B
C
B
C
Expect
I
think
some
of
this
I
don't
know
how
much
this
is
going
to
be.
You
know
easy
to
resolve
within
Kubo
with
like
more
magic
Flags,
but
it
certainly
should
be
fixable
because
there's
not
really
much
utility
you're
getting
out
of
egress
bandwidth
to
everybody
unless
it's
all
coming
from
like
legitimate
that
swap
wants,
but
that
doesn't
seem
reasonable
either.
B
E
But
we'll
see
we'll
we're
gonna,
so
Dennis
is
looking
at
this
problem
and
he's
gonna
talk
about
it
this
week
at
the
program
website,
because
he
found
some
surprising
numbers
when
looking
at
the
Hydra
data
that,
like
according
to
that
data,
like
a
huge
proportion
of
this,
was
just
like
the
P2P
overhead,
like
connection
handshakes
and
stuff
like
that,
so
he
might
have
some
interesting
results
soon.
On
this.
B
A
A
So
these
are
all
the
topics
that
we
had
planned
to
cover
for
this
work
group
meeting
number
three,
usually
at
the
end
of
the
meeting
for
folks
that
haven't
been
here
before
we
do
a
round
table
kind
of
top
of
Mind
from
each
of
the
contributing
teams.
So
it's
kind
of
a
free-for-all
opportunity
to
bring
up
topics
that
you'd
like
discussed.
While
you've
got
this
audience.
C
E
C
C
E
C
A
Well,
I
think
we've
covered
all
of
our
topics
here,
so
we
can
have
a
little
bit
of
time
back
I
will
do
the
the
needful
thing
and
go
ahead
and
kind
of
aggregate.
The
outcomes
from
this
discussion
towards
the
bottom
of
the
notes
here
but
I'll
be
posting.
Those
in
the
content
more
group
slack
afterwards,
so
no
need
to
follow
up
on
this
you'll
see
that
update
there
as
well.