►
From YouTube: 2023-07-23 Content Routing Workgroup #16
Description
CLI updates to IPNI, IPFS /routing/v1 update to Kubo v0.23, Bifrost continued v0.21 rollout. Delegated double hashing and ambient discovery on the horizon, but when requires further discussion.
A
A
That's
being
done
presently,
we
usually
start
this
meeting
every
time
with
a
quick
update
from
the
teams
that
participate,
because
we've
got
a
really
good
breadth
of
kind
of
visibility
into
what's
going
on
around
the
network.
Here
on
these
teams,
I'll
start
with
an
update
from
the
ipni
team
and
then,
if
the
ipfs
folks
from
Prov
lab,
would
like
to
jump
in
we'd
love
to
hear
about
y'all.
A
So,
on
the
ipni
side
of
the
house,
the
foundation
DB
experimentation
is
ongoing,
but
we've
hit
some
pretty
pretty
hard
obstacles.
The
backing
database
for
foundation
DV
has
a
memory
leak
that
I
think.
Once
we
hit
a
certain
amount
of
scale,
potentially
Mossy
correct
me
if
I'm
wrong,
there
may
have
been
other
factors
that
contributed
to
this,
but
essentially
the
important
point
to
take
away.
Is
we
had
a
very
painful
memory
leak?
We
think
we've
got
a
replacement
backing
database.
That
would
potentially
be
a
good
candidate
that
resolves
this
issue.
A
However,
the
real
question
for
us
is
whether
or
not
we
have
the
resources
to
continue
this
level
of
experimentation
right
now,
and
so
we've
got
a
lot
of
internal
considering
to
do
regarding
our
path
forward.
But
for
the
time
being,
the
important
takeaway
from
the
group
is
foundation.
Db
will
not
be
live
in
production
anytime
soon
for
IP
and
I
we're
continuing
with
The
Rock
Solid
continuing
to
serve
as
Pebble
DB,
which
is
rocking
along
heartily
right
now.
A
Hence
the
reason
why
probably
nobody
even
noticed
that
we're
having
these
problems
because
we're
serving
such
redundant
infrastructure
right
now
and
on
top
of
that
speaking
of
redundant
infrastructure,
we've
been
kind
of
undergoing
a
pruning
exercise
with
our
infrastructure
over
the
course
of
the
last
three
weeks
that
I
gotta
heartily
give
some
Applause
to
both
Mossy
and
Andrew
Gillis
for
really
Bringing
Down.
The
scope
of
infrastructure
costs
on
ipni
consistently
week
over
week,
three
weeks
running,
big
numbers
and
we've
done
so
without
reducing
any
of
our
reliability
or
redundancy
as
well.
A
I
think
from
the
looks
of
things,
our
performance
has
stayed
perfectly
the
same,
and
so
there's
a
lot
to
be
applauded
there.
Additionally,
there's
something
worth
checking
out
which
is
Andrew,
updated
our
CLI
and
included
some
really
helpful
distance
commands
that
I
think
folks
in
this
group
might
be
a
little
interested
in
I'm
talking
to
him
about
if
we
can
show
them
off
in
one
of
our
demo
days.
That's
coming
up,
but
folks
here
might
be
interested
if
he
doesn't
want
to
show
them
off
in
the
demo
day.
A
I
might
run
them,
but
either
way,
I'll
share
a
link
to
the
folks
in
this
group.
When
that
happens,
basically,
you
can
check
the
distance
any
given
provider
is
from
the
ipni,
but
also
you
can
do
a
standard
out
from
your
terminal
with
the
CLI
command.
That
shows
you
kind
of
the
the
running
logging
of
providers,
which
there's
all
kinds
of
interesting
insights
that
you
can
gather
about.
The
current
state
of
providers
on
the
network
from
this
data.
A
If
they
are
timing
out,
then
their
their
data
is
not
becoming
queryable
on
ipni,
and
so
our
proposal
to
fix
this
solution
is
to
take
a
look
at
this
data
transfer
protocol
and
clean
it
up.
We've
got
a
design
document
that
we've
just
started
iterating
on
with
kind
of
our
our
internal
team.
Probably
we
can
share
that
with
the
broader
group.
A
I
think
maybe
once
folks
have
had
a
first
pass
on
it,
but
we'll
get
that
out
there.
It
would
create
a
dependency
on
the
provider
in
boost,
so
we
would
have
to
update
boost
to
get
this
out
to
the
network,
but
we're
in
the
midst
of
discussing
what
that
kind
of
rollout
would
look
like
and
how
we
would
support
both
both
protocols
for
the
time
being,
as
folks
update
to
that
new
version
of
this.
So
those
are
the
big
updates.
C
Let's,
what's
the
trick,
what's
the
trick
in
supporting
more
than
one
protocol
seems
like
you'd
have
like
you
have
you
have
identify
and
whatever
so
you
should
be
able
to
just
say:
do
you
speak?
Do
you
which
protocols
do
you
speak?
Let
me
try
the
one
I
prefer,
and
so
then
you
have
both
code
paths
and
then
you
deprecate
the
one
you
don't
like
when
you
feel
like
you're
able
to
kill
it
off
because
enough
people
have
updated.
A
C
A
D
D
So
we
have
streaming,
we
have
ipns,
but
we
don't
have
peer
routing.
So
there's
like
an
open
IP,
which
I
linked,
which
introduces
a
peer
schema,
will
most
likely
only
use
a
subset
of
that,
but
they're
just
flagging
that
this
will
be
a
way
for
closing
functional
gap
of
the
routing
API
and
that's
part
of
a
bigger
picture
where
we
want
to
have
a
ability
to
do
everything
ipfs
over
HTTP.
There
should
be
like
anything
you
can
do
today.
D
So
that's
just
kind
of
PSA
why
that
PR
will
be
in
a
country
point
for
a
bunch
of
work
and
the
second
one
is
I
just
published
a
draft
of
ipns
cleanup.
It's
an
early
draft
tldr
is
that
we
we
duplicated
old
signatures,
but
we
still
published
records
which
had
both
of
them
and
even
when
both
client
and
server
only
cared
about
the
new
signature.
The
lack
of
the
old
signature
made
records
invalid.
D
D
D
D
We
have
optional
public
key
for
RSA
keys
and
we
have
a
signature
and
a
c
bar
document
and
the
signature
science,
entire
symbol
document,
so
there's
like
fairly
the
surface
is
very
fairly
small,
and
if
people
implemented
the
protobuf
envelope
before
the
only
difference
will
be
in
validation
and
what
this
IP
documents
is,
the
change
in
the
way
we
create
records
to
make
them
lean
and
also
how
to
validate
things
so
building
records
are
still
valid.
What.
D
D
We
would
like
to
ideally
return
a
record
in
peer
schema
instead
of
like
unknown,
but
that's
kind
of
like
a
cosmetic
thing.
Implementations
at
least
in
go
in
JS,
will
also
like
support
and
unknown
just
to
make
a
smooth
transition
path.
But
for
for
the
spec
and
for
the
new
implementations
will
be
pointing
people
in
the
direction
that,
if
you
don't
know
that
the
specific
protocol
or
you
don't
have
any
protocol
specific
information
metadata
just
return
peer
record
and
with
multi
others
and
that's
good
enough.
D
A
A
E
Yeah
sure
we
in
the
process
of
rolling
out
0
21
at
the
moment
seems
I
think
we
just
skip
0
20
entirely
for
some
reason.
So
that's
what
we're
hoping
to
get
out
at
the
moment
so
we'll
have
those
stats
for
you
guys
at
the
moment.
It's
still
isolated
to
that
that
one
region
that
we
had
the
test
deployment
in
unfortunately,.
E
C
B
C
C
E
C
F
E
A
Awesome
thanks
Cameron
I
didn't
check
today,
but
I've
been
checking
periodically
and
it
seems
like
the
the
stats
pages
from
bifrost.
Team
have
been
keeping
up
to
date,
so
it's
it's
been
helpful
to
be
able
to
check
the
status
of
those
things,
I'm,
not
sure
if
anybody
else
has
been
referencing
them,
but
I
occasionally
check
just
to
make
sure
we
can
see.
What's
going
on
as
stuff
comes.
E
Up
just
so,
you
guys
aren't
misled.
Those
statues
seen
currently
are
only
from
that
test.
Rollout.
We
had
of
the
to
I
think
they're
in
Las
Vegas,
if
I'm
remembering
the
right
region
anyway,
it's
not
important,
but
it's
only
a
small
sample.
It's
not
all
of
the
Gateway
nodes,
that's
the
main
takeaway.
So
as
soon
as
we
get
21
a
one
out,
we'll
have
everything
properly
clarify.
A
A
There
is
a
PR
for
the
hdb
delegated
delegated
routing
for
reader,
privacy
and
I.
Think
there's
been
some
discussion
on
that
PR,
but
there's
some
work
to
be
done
on
also
the
stewards
side
of
the
house
and
I
think
we
were
wondering
on
where
this
Falls
and
the
like
a
priority
list
of
stewards.
Is
this
going
to
get
worked
on
this
quarter?.
D
C
Yeah
I
think
we're
we
are
still.
We
are
still
negotiating
what
the
the
end
results
of
the
prioritization
is
going
to
look
like,
but
my
suspicion
is
that
this
isn't
going
to
come
up
super
high
unless
there's
someone
specifically
pulling
for
it
from
us,
in
which
case
you
know,
I
feel
like
we're
trying
to
sort
of
like
amplify
our
our
impact
and
so
like.
C
F
C
C
B
B
B
So
it's
ready
for
review
and
then,
after
that,
implementation
in
box,
so
and
then
integration
into
Kubo,
but
the
the
side
thing
that
slightly
worries
me
is
just
having
this
feature
only
in
ipni
until
q124
shipping
it
here
because
we
have
it
already
and
all
that's
missing
is
like
the
glue
bit
in
in
Google.
If
that
makes
sense,.
C
Those
things
may
not
be
dissimilar
enough
for
anyone
to
care
until
there's
a
second
thing
that
wants
to
use
it
right,
so
it
kind
of
I
could
see
I
could
I
guess.
I
could
see
that
going
either
way
right.
If
we
don't
feel
like,
we
have
enough
confidence
in
building
in
building
like
a
somewhat
generic
API,
given
we
only
have
one
backing
implementation,
so
you
don't
have
confidence
to
do
that.
Yet
then
saying
okay,
well,
we'll
use
the
specific
API
for
now
and
then
make
a
generic
one
once
there's.
C
That's
why
I
guess,
like
that's
sort
of
the
good
thing
is
like
we
don't.
The
API
here
doesn't
need
to
be
the
the
blocker
right.
If
we
have
multiple,
if
we
have
multiple
service
providers
that
are
providing
data,
and
we
have
some
code
and
some
some
Logic
for
determining
sanely
how
to
decide
which
ones
to
use
and
sort
of
the
how
synchronized
everything
is,
then
that's
probably
enough
to
get
the
ball
rolling
little.
Do
you
disagree
sound
about
right.
D
A
That's
a
good
takeaway
I,
don't
know
if
you're
thinking
about
it
we're
we're
in
good
shape,
thanks
y'all
for
the
perspective
on
that
I
think
it
gives
us
something
to
think
about,
and
maybe
once
you
all
have
had
some
time
to
think
about
it.
We
can
talk
a
little
bit
more
about
where
a
false
priority
was
kind
of
based
on
renewed
understanding.