►
From YouTube: 2022-12-13 IPFS Content Routing WG #2
Description
Sync of those involved with creating IPFS Content Routing proposals. Meeting #2
HTTP delegated routing is partially implemented, this discussion centers on the remainder of implementation. We also cover details of the now-defined spec for reader privacy on double hashed CIDs and efforts to close the year out/begin efforts for Q1.
Notes:
https://www.notion.so/pl-strflt/2022-12-13-Content-Routing-WG-1f750f7e0aec4086a48be2448634b1c0
For more on the IPFS Implementers Sync including calendar information see:
https://www.notion.so/pl-strflt/Content-Routing-Workgroup-e59fa94a9c3f48d58480b7daf15bd356
Website: https://ipfs.io/
Twitter: https://twitter.com/IPFS
B
A
Opportunity
to
leave
now
so
I
put
together
an
agenda
here.
I
have
the
hopes
that
this
meeting
actually
doesn't
need
to
be
an
hour
and
effectively.
We
can
potentially
compress
it
down
to
45
minutes
or
even
half
an
hour,
maybe
we'll
Target
45
minutes
today,
since
we're
heading
into
the
holidays.
But
if
we
do
have
kind
of
longer
discussions
about
any
of
these
topics,
we'll
have
the
space
here
for
it
and
we'll
continue
to
try
to
eat
less
of
everyone's
time.
If
possible,
I've
thrown
an
important
document
section
up
here.
A
B
A
It
doesn't
have
usually
it
has
the
green
glowing
box
around
it
to
indicate
that
it's
sharing
the
screen,
but
it
doesn't
right
now
all
right.
So
the
purpose
of
this
meeting
is
we're
going
to
focus
on
kind
of
some
of
the
aspects
of
the
technical
implementation
of
double
hashing,
that's
being
proposed
right
now,
and
any
feedback
or
questions
concerns
regarding
potentially
future
implementations
of
ambient
content.
Routing
I
think
we
just
got
some
notes
from
will
last
night
that
may
guide
our
conversation.
C
C
So
in
terms
of
where
this
has
rolled
out,
cad.contact
has
this
in
production
it
has
HTTP
delegated
routing
and
production.
I
believe
if
I
saw
that.
So,
if
we,
you
can
click
into
the
issue
that
I
linked
above
but
hydra's
I,
guess
hasn't
deployed
yet
because
he
was
noticing
a
problem
with
CPU
usage,
so
I
think
he's
identified
it
he's
going
to
then
deploy
today.
C
So
we
should
get
the
hydros
deploying
today
and,
as
little
has
listed
here,
Kubo
0.18
by
default
uses
delegated
routing
HTTP
delegated
routing,
hitting
CID
contact
and
we're
cutting
the
RC
today.
Maybe
it's
already
been
already
been
done
so
that
that's
all
good
there's
also
the
aspect
of
rolling
this
out
to
the
gateways
and
it
looks
like
the
Gateway
is
just
recently
deployed:
reframe
integration
from
the
itfest.io
gateways
to
cid.contact,
but
there's
a
follow-up
deployment
that
needs
to
occur
that
uses
HTTP
delegated
routing
from
the
gateways
to
cid.contact.
A
C
No
yeah
another
notion
notes
yeah,
thank
you,
Massey
yeah,
two
and
eight
three
yeah.
So
I
don't
know
like
this
issue
was
tracking
the
reframe
rollout,
but
we
need
to
again
come
through
and
do
a
rollout
that
actually
switches
to
using
HTTP
delegated
routing
so
like
I'm,
assuming
obviously
it
kind
of
took
months
to
do
this.
Rollout
with
bifrost
with
reframe
I,
want
to
make
sure
somebody
is
owning.
Doing
the
bifrost
rollout
with
HTTP
delegated
routing.
A
Yes,
I
did
follow
up
on
that
when
you
brought
it
up
Steve
and
they
have
a
new
engineering
manager
over
there.
I
don't
know
if
you
all
have
talked
to
him
yet
his
name's
Cameron
wood,
okay,
but
let
me
grab
the
name.
Sorry
I,
don't
know
everybody
yet,
but
still
still
getting
the
hang
of
that,
but
somebody
is
assigned
to
it
and
they
were
out
this
week,
but
I
think
their
goal
was
to
have
it
wrapped
up
by
Friday.
C
So
well,
and
to
be
to
be
fair,
like
this
is
the
HTTP
delegated
routing
code
paths
in
Kubo
are
are
new
like
there's
a
there
was
a
bunch
of
new
code
that
got
written
over
the
last
month.
We
just
are
doing
the
RC
today,
so
like
I,
don't
think
it's
probably
prudent
for
us
to
be
pushing
this
all
out
by
by
Friday,
but
it's
going
to
need
to
bake
for
a
day
or
two
I
mean.
But
the
point
is
like
this
is
more
than
a
configuration
change
there
is.
C
There
is
new
code
here
and
so
like
I
would
want
to
make
sure
that
bifrost
team
is
aware
of
that,
and
are
you
approach,
sorry
responding
with
appropriate
care,
like
obviously
I
would
love
to
go
into
the
break
with
this
being
fully
done,
but
we
need
to
be
safe
and
yes,
but
I.
Just
most
important
thing
is
I
just
want
to
make
sure
it
gets
owned
and
it
doesn't
fall
through
the
cracks
for
two
months.
A
It
is
owned,
so
Mario
Camus
is
on
it
hope,
I'm
saying
that
last
name
correctly,
but
I
can
check
in
with
him
and
just
make
sure
that
the
scope
of
work
reflects
and
entirely
what
you've
described.
Steve,
if,
if
you
want
to
okay,
if
you
have
is
the
entirety
of
what
you
just
described
in
the
GitHub
issue,
that
I
can
walk
through
with
them.
C
C
B
B
C
C
C
I
I
mean
I,
think
it's
a
class
of
metrics
right.
There
is
you,
you
guys
set
up
a
class
of
metrics
for
when,
like
I
guess
there
was
the
original
indexer
find
provider's
endpoint.
Then
we
added
reframe
and
now
we've
added
HTTP
delegated
routing
ipip337
I
just
want
to
make
sure
at
some
point
here
in
the
future.
The
the
hydras
and
the
ipfest.io
gateways
are
going
to
switch
from
using
reframe
and
instead
use
delegated
routing
and
I
want
to
make
sure
that
you
guys
still
have
visibility
to
that.
D
C
Very
cool
all
right,
so
then
I
think
the
the
really
the
two
open
things
here.
Well,
I
guess
the
three
just
in
summary,
hydra's
got
to
get
deployed.
Gus's
guesses,
on
that
today,
Kubo
0.18
has
to
move
from
an
RC
to
an
actual
final
release.
The
Kubo
team
is
on
that
and
then
the
third
is
that
the
bifrost
ipf
Studio
gateways
need
to
deploy
using
delegated
routing
through
Kubo
0.18
and
I'm
gonna.
Let
bedrock
and
bifrost
work
that
out
make
sure
that
happens.
D
E
A
Let's
jump
into
the
exciting
topic:
double
hashing
design
pathway,
so
we
have
the
reader
specification.
Has
everybody
here
had
a
chance
to
read?
It
don't
feel
bad
if
you
haven't,
we
can
take
a
moment
and
kind
of
parse
through
it
like
that
benefits
the
crowd.
If
everybody
has
read
it,
we
can
just
jump
into
the
discussion
topics
thumbs
up
any
other
Thumbs
Up
Everybody,
giving
it
a
look
thumbs
down.
Let's
pull
it
up
and
take
a
look
at.
A
C
C
Cool
okay,
make
mixes,
yeah
I,
think
that's
I
mean
it
makes
sense.
I
I,
just
think
I
would
just
make
sure
that's
called
out.
I
think
I
need
to
be
emphasized
more
again.
It's
not
to
hey
I,
don't
I!
Don't
want
that
to
be
a
surprise
to
someone
later.
You
know
it's
obviously,
so
much
of
the
push
around
using
indexers
was
around
about
reducing
round
trips
and
go
to
minimize
sorry
to
minimize
speed
of
light
impacts,
and
you
know
we
we
absolutely
legitimately
have
to
add
one
here.
C
A
I
will
say
one
thing:
I
wanted
to
draw
your
attention
to
Steve.
That
I
didn't
see
from
the
original
comments
is
that
upon
testing
we're
seeing
pretty
significantly
reduced
performance
impacts,
so
now
that
we've
got
a
POC
that
we're
testing
on,
we
had
originally
stated
a
10x
impact
and
we're
drawing
it
down
to
1.5
x.
Obviously,
that's
not
in
production,
so
you
know
we
want
to
be
wary
with
advertising
that
broadly,
but
I
think
the
team's
pretty
pretty
confident
with
what
we're
seeing
presently.
E
I
I
have
like
a
meta
question
or
suggestion
for
the
spec
kind
of
like
having
a
thread
model
section
clearly
describing
what's
the
threat
model
that
we
are
protecting
from
I.
Think
that
would
benefit
would
be
like
really
make
it
easier
for
people
to
engage
in
this
discussion,
because
this
there
are
like
multiple
specs
which
are
not
in
the
scope
like
the
writer
privacy
is
not
in
the
scope,
the
retrieval
privacies,
it's
not
in
the
scope.
E
Yeah
because
kind
of,
like
another
meta,
I,
think
it's
like
that
type
of
questions
were
like
asked
from
Partners
like
Brave.
There
are
like
super
privacy
conscious
and
their
security
team.
That's
the
first
question
so
having
that
written
down
as
a
part
of
spec
will
avoid
like
round
trips
across
the
Orcs.
A
Yeah,
this
is
a
good
perspective.
Liddell
I
dropped
a
white
paper
that
I
was
recently
reading
into
the
into
the
chat
I
think
that
speaks
specifically
to
some
of
the
kind
of
potential
malicious
actor
activities
that
were
I.
Think
addressing
with
this
enhanced
capability,
but
I'd
be
curious
to
hear
your
opinions
on
that.
E
C
G
Something
that's
sticks
out
to
me
is
the
so
maybe
that's
not
very
relevant
I
would
just
put
it
out
anyway.
So
there's
this
so
the
spec.
It
says,
like
it's
hashing,
something
everywhere.
Do
we
double
down
on
a
specific
hashing
function?
Do
we
also
use
a
multi-hash
for
that?
Do
we
is
there
some
upgraded
upgrade
path
for
the
future
that
we
should
keep
in
mind
here.
Just
some
questions.
F
Yes,
a
great
question
so
we're
specifically
left
the
exact
encryption
out
of
the
out
of
scope,
so
basically
we're
just
exactly
aligned
with
what
DHT
implementation
is
to
make
sure
that
they
use
exactly
the
same
thing.
So
the
moment
is
like
Charter
56
for
crashing
and
AAS
in
GCM
modes,
I!
Think
for
encryption!
Basically,
the
same!
That's
these
implementation
is
using.
G
Right
right
and
could
have
become
a
problem
at
some
point
if
we
wanted
to
upgrade
something
in
the
in
the
protocol
or
in
in
the
spec.
If
we
used
own
traffic
256
only
I
I
remember
that
in
the
current
DHC
implementation
we
also
just
a
shot
to
56
hashing,
all
the
multi-hashes
and
to
get
to
Common
key
space
for
cids
impurities
and
I.
Actually,
don't
remember
why
we
did
that
I
think
it's
just
to
to
arrive
at
the
common
key
space
for
for
both
types
of
like
prds
and
cids.
G
F
H
But
it
should
be
your.
Can
you
hear
me?
Yes,
okay
I
agree,
so
it
should
be
so
basically
the
last
hash,
so
here
the
second
hash
should
be
the
same
hash.
That
is
already
let's
say:
we
unifying
the
peer
ID
space
and
the
create
space.
So
when
we
decide
to
migrate
this
periodcid
space
to
another
one,
we
will
also
change
the
second
hashing
function,
so
the
function
should
be
the
same
here.
H
F
Yeah,
so
that's
basically
remains
unchanged.
So
exactly
the
same
as
it
is
now
so
it's
kind
of
like
in
the
beginning.
It
mentions
that,
like
writer's
privacy
is
out
of
scope,
basically
they're
going
to
use
exactly
the
same
advertisements
and
Etc.
So
we
are
focusing
explicitly
on
the
on
the
on
the
reader's
path,
doesn't
make
sense,
but
yeah
go.
B
D
F
So
the
clients
would
send
requests
to
Hash
up
the
clash
of
the
multi-hash
from
CID,
and
the
indexer
would
reply
with
encrypted
peer
ID.
The
client
would
decrypt
the
dear
ID
using
the
original
multihash.
Then
they
would
calculate
a
hash
over
the
decrypted
period
would
send
it
to
the
indexer,
and
the
indexer
would
reply
would
provide
a
record
that
is
encrypted
with
the
original
priority.
The
client
could
receive
the
the
record
and
would
decrypt
it
with
the
original
period
and
can
use
it
to
reach
out
directly
to
the
provider.
F
Id,
so
the
yes,
so
apologies,
so
there
was
a
wrong
link
to
the
spec
in
the
beginning.
Okay,
so
if
you
follow
the
link
that
Antonio
have
dropped
earlier
in
the
charts,
basically
I
will
just
copy
and
paste
it
all
right.
Basically,
I've
I've
changed
that,
so
it
was
yeah.
It
was
recent
wrongly.
So,
basically,
yes,
it
was
reply
with
the
with
the
full
purity.
F
E
G
F
D
Can
talk
the
advertisement
side
is
the
thing
we
are
calling
writer
privacy,
which
is
we
we're
calling
it
out
of
a
scope,
so
just
to
clarify
this
is
concentrates
on
the
reader
privacy,
which
means
after
the
indices,
have
ended
up
on
the
index
there,
then,
the
indexer
can't
observe
the
query
traffic
to
gather
statistics
on
a
this.
Is
the
CID
that's
being
queried?
D
This
is
a
popular
one,
and
this
is
the
provided
as
popular
song
right,
but
indexer
is
still
in
a
position
that
it
could
obviously
see
all
the
advertisements
that
are
published
by
the
digital
sensors,
and
you
know
you
have
everything
unencrypted
the
on
the
observability
of
the
whole
network.
The
the
key
thing
to
point
out
is
that
read
their
privacy
alone
makes
it
more
expensive
to
just
crawl
the
network
and
to
gather
information,
because
you
would
then
have
to
crawl.
The
entire
network
consume
each
advertisement
chain
to
make
make
a
bigger
picture.
D
B
D
We
currently
don't
have
any
plans
for
implementing
that,
but,
okay,
now
that
you
mentioned
this
is
interesting.
I
think
it's
worth
capturing,
because
the
data
structure
we
use
in
the
back
end
could
facilitate
that
easily.
You
know
we
don't
have
to
do
extra
engineering
to
make
the
prefix
based
lookup
possible,
which
is
we
just
have
to
expose
it.
F
F
H
It's
just
to
get
K
anonymity
on
the
request,
which
is
so
and
get
plausible
deniability.
So
when
I
make
a
request,
I'm
not
requesting
exactly
the
CID
I'm
looking
for,
but
the
prefix
of
it
and
then
either
the
DHT
or
the
indexer
should
return
me
all
of
the
provider
record
matching
this
prefix.
So
it
may
be
I,
don't
know
five
or
ten
or
two,
and
so
that
the
entity
giving
me
the
provider
recalled.
We
will
not
know
exactly
which
content
I'm
accessing
got
it.
So
there's
a
small
Network
overhead
but
yeah.
C
F
Yeah
sure
so,
wherever
we
are
so
we
do
have
the
specs.
So
I
will
let
a
few
bits
and
Bots
that
have
me
saying
that
we
discussed
we
do
have
APR
already
that
implements
the
proposed
change
against
the
data
store
that
we
use
in
indexing.
So
we
do
have
performance
measurements
kind
of
like
there
is
an
MVP
for
that,
so
PR
the
PRN
used
to
be
brushed
up.
So
we
need
to
think
about
migration.
So
there
are
data
migration.
There
are
no
unresolved
change
challenges
there.
F
F
So
the
reasons
the
statical
user
Journey
that
one
needs
to
do,
for
example,
if
you
want
to
look
up
a
hash,
you
need
to
you.
If
you
want
to
look
up
a
seat,
you
have
to
take
a
hash
of
it,
then
do
like
a
bunch
of
things
and
like
just
sequence
of
steps,
so
I
also
I
think
it's
suffice
to
like
Implement.
Maybe
that's
in
some
reusable
functions
so
that
others
can
just
take
it
and
use
it
so
must
I
do
have
any
any
thoughts
on
that.
C
Cool
okay
sounds
sounds
good,
yeah,
okay,
it
makes
sense,
it
might
be
just
I,
don't
know
if
you're
aware.
Obviously
we
had
that
separate
delegated
routing
new
client
and
server
Library.
We
ended
up
just
pulling
that
into
the
go
lib
ipfs
repo,
we're
starting
to
build
like
kind
of
a
mono
repo
of
all
these
kind
of
related
utilities
and
packages
so
that
releasing
and
staying
you
know
and
having
consistent
you
have.
C
D
That's
a
great
chart,
so
we're
hopefully
Gus
would
be
there
in
Switzerland
when
we
meet
up
so
we've
got
to
iron
these
details
out,
but
the
the
library
that
I
had
in
mind
is
agnostic
of
ipfs
right,
it's
just
a
library
to
interact
with
indexer
yeah,
but
but
yeah.
We
will
iron
out
the
details
of
how
this
would
play
out
with
the
HTTP
delegated
route.
Okay,
very
good.
C
H
C
F
Yeah
also
go
ahead,
just
like
a
small
point,
so
tomasi
that
the
a
reader
it's
not
either
or
so
we
can
basically
serve
both
bars.
We
can
sort
of
normal
path
and
the
private
part
when
we,
when
the
things
land,
so
it
doesn't
have
to
be
like
migration
like
just
cut
off,
can
be
gradual
migration
of
clients.
C
I
was
taking
the
push
there
from
Massey
of
like
let's
focus
on
the
Privacy
related
changes
ahead
of
like
ambient
Discovery
changes,
obviously
still
within
privacy.
There's
it
is
released.
Client
ends
like
Kubo.
We've
got
to
think
about
DHT
and
indexer,
but
I
think
I
I
would
agree
like
let's,
let's
land
the
Privacy
work
ahead
of
getting
caught
in
specs
around
ambient
Discovery
Etc
I
want
to
solve
that
too.
But
I'm
fine.
For
that
to
be
the
follow-up.
A
C
C
Gee
I,
don't
know
how
much
this
audience
is:
paging,
I,
don't
know
and
I
again.
If
there's
I'm
asking
some
dumb
questions,
just
let
me
know
it
sounds
like
chainsafe
is
also
involved
here.
Do
you
want
to
just
kind
of
give
the
update
and
I
don't
know
if
it
makes
sense
to
pull
any
of
that
crowd
here
like
this?
Is
intended
to
be
kind
of
any?
Not
that
all
not
that
all
conversations
about
content
running
have
to
be
here
but
like
we
want
this
to
be
open
beyond
just
pln
dress
groups
too.
H
Yeah
sure
so,
basically
so
there
was
a
first
design
of
the
spec
that
changed
safe
is
currently
implementing,
so
the
implementation
is
mostly
done
and
they
still
need
to
figure
out
test
ground
for
the
testing.
So
it's
still
kind
of
hard
to
test
the
implementation
at
the
moment,
but
most
of
the
work
should
be
done.
H
We
figured
out
that
there
is
a
small
privacy
concern
in
the
initial
design,
so
the
design
would
require
some
more
work,
so
either
we
could
go
ahead
and
migrate.
What
we
already
have
now-
let's
say
as
a
first
step
and
then
correct-
or
let
us
finish,
the
design
and
implement
the
the
second
version
to
correct
this
small
privacy
default
and
push
the
second
change
in
a
second
step.
H
But
at
the
same
time
we
really
want
to
minimize
the
number
of
DHT
migration,
because
that's
painful.
We
need
to
duplicate
the
network,
which
means
that
all
content
provider
will
need
so
during
the
transition
period
to
publish
content
on
both
the
Old
and
the
new
DHT
which
we
want
to
avoid,
and
the
clients
will
want
to
request
content
from
both
because
they
don't
know
where
it's
stored.
H
And
so
we
want
to
really
minimize
the
number
of
migration.
So
my
stand
is
more.
Maybe
it's
worthy
to
wait
a
bit.
We
can
already
ship
the
reader
privacy
for
the
index
service
because
we
don't
need
to
wait
for
the
DHT,
but
maybe
have
one
single
log
change
for
the
DHC,
including
an
upgradable
DHT
design,
which
will
allow
us
to
then
migrate,
pain,
painlessly,
the
the
DAC
for
all
for
future
migration
concerning
privacy
or
other
designs.
C
C
Yeah.
Obviously
we're
introducing
something
new
with
the
indexers
which
are
more
Consolidated
and
so
I
think
solving
some
of
the
reader
privacy
issues.
There
is
more
Paramount,
we've
got
limited
resources,
letting
the
engineering
team
focus
on
that.
While
you
know
probe
lab
and
others
are
doing,
the
DHT
stuff
right,
I
think
make
makes
sense.
The
do
we
have.
Is
there
an
ipip
with
the
DHT?
C
B
H
C
Okay
and
I-
guess,
like
you
know,
like
obviously
Mossy,
is
tied
in
with
folks
like
Gus
about
how
this
would
roll
into
things
like
Kubo.
Has
that
kind
of
conversation
been
happening
on
the
DHT
side
of
double
hashing?
How
we'd
actually
I
know
Kubo
is
not
the
only
implementation,
but
that's
obviously
one
of
the
implementations
we
care
about.
C
C
A
B
A
A
D
Gonna
I'm
sorry
I
just
want
to
find
that
on
the
coupling
thing,
I
think
we
should
write
down
what
Steve
pointed
out,
which
is
the
specification
for
HTTP
yeah.
We
don't
have
that
yet
right,
but
we
will
have
it
by
the
end
of
January
after
the
Cola
in
Switzerland.
So
that
is
the
only
point,
a
sticking
point
in
independencies,
but
so
far
from
a
technical
perspective,
looking
at
the
spec
that
Ivan
put
together,
we
don't
see
any
obvious
problems.
Right,
I
think
that's
a
very
does
that
make
sense.
Steve.
C
A
A
C
A
And
then
I
realized
after
rereading
through
this
thanks
masi
for
pointing
out
the
ipns
index
or
ingestion,
is
the
way
that
I'm
summarizing
this
non-naming
system.
I'd
like
to
ask,
is
the
content
writing
work
group
the
appropriate
place
to
discuss
this
topic
or
take
care
Ivan
thanks
or
is
this
outside
the
context
of
this
group.
D
Concentrating
on
the
in
progress,
stuff,
I
think
this
is
also
a
backbanner
item,
but
I've
been
pushing
it
forward
and
the
reason
for
pushing
forward
is
IPS
is
part
of
the
routing
system.
So,
if
you
want
to
provide
a
grounded
routing
system
alternative,
we
need
to
solve
ipns
inside
the
ipni
or
extreme,
so
for
now,
I,
don't
think
we
should
spend
time
discussing
it
until
PR
is
reviewed
and
so
on,
which
I'm
pushing
for
okay.
D
A
Perfect,
so
we
are
officially
at
time
I'll
just
kind
of
summarize
there's
a
bunch
of
action
items
here,
I'll
aggregate
them
and
make
sure
that
they're
communicated
as
well
out
to
the
slack
Channel
and
I
did
drag
some
kind
of
outcomes
from
the
prior
meeting
here
to
review.
If
anybody
wants
to
to
take
a
look
at
them,
including
some
of
the
feedback
that
I
thought
was
important
from
leadership
during
our
our
last
leadership
outcome,
but
other
than
that
great
meeting
thanks
everyone
for
joining
I,
really
appreciate
it.
Yeah
and
Steve.
C
In
there
before
we
go
well,
no
I
did
want
to
say
thank
you
all
for
the
involvement
here
and
I
I
think
you
had
a
question
about.
Should
the
indexer
and
naming
system
be
in
this
call
and
I
think
this
is
the
appropriate
place
to
probably
be
discussing
is
at
least
one
of
the
appropriate
places
to
be
discussing
those
kind
of
specs
I
know
it's
not
top
of
the
list
right
now,
but
I
think
it's
it's
good
to
be
surfacing
those
here
and,
of
course
this
is
probably
the
Right
audience
to
be
digging
in.