►
From YouTube: 2022-05-12 IPFS Implementers Sync
Description
Notes: https://pl-strflt.notion.site/IPFS-Implementers-Sync-2022-05-12-b338b20567904923b3772c58f1c9186c
For more on the IPFS Implementers Sync including calendar information see: https://pl-strflt.notion.site/66bc757298674c1bac6885ecec1b3085?v=732024816bdf4a2aac18d7fd8764223a
A
Yes,
this
is
hey
everybody.
This
is
the
ipfs
implementers
call
for
may
12.,
I'm
going
to
start
off
with
some
agenda
items
brendan.
B
Yeah,
so
I
I
just
wanted
to
announce
is
a
very
like
quickly
put
together
workshop
happening
next
friday
around
exploring
the
need
for
ipfs
implementations.
We've
been
talking
to
juan
about
it.
B
He
really
wants
to
see
this
happen,
and
so
none
of
us
are
going
to
just
explore
the
concept
around
it,
and
so
I
wanted
to
join
this
call
to
invite
a
few
of
you
in
particular
to
speak,
and
if
anybody
thinks
they
have
something
specific
to
say
around,
the
topic
would
be
great,
I
think
so
far
I've
just
been
organizing
who
is
speaking
and
running
agendas.
So,
if
you
want
to
do
any
of
that
chat
to
me,
you
can
talk
for
any
amount
of
time.
B
Five
minutes
to
45
minutes,
I
think,
is
sort
of
the
range
that
we're
targeting
yeah.
And
so,
if
you
have
things
to
say
about,
I
profess
implementations,
potential
opportunities,
potential
pain,
points-
things
you
wish
exist
things
you
think
could
be
great
if
we
all
work
together
in
a
specific
way.
On
a
specific
thing,
you
want
to
talk
about
specs
and
why
specs
are
a
great
thing
for
lots
of
implementations.
You
want
to
talk
about
interop
testing.
Why
interrupt
testing
is
a
really
important
thing
and
hard
to
do
right.
A
B
A
Is
it
app
e5?
Yes,
it
is
d5
on.
B
I
think
yeah
it's
specialized
topics
that
give
folks
have
specific
things
they
want
to
talk
about
in
a
round.
It's
we're
trying
to
set
aside
four
hours
to
get
some
good
recordings,
so
this
will
be
online.
It's
obviously
not
an
in-person
thing,
yeah
and
I'll
try
and
do
a
little
coordination
of
like
who's
speaking
on
what
so
that
we
can
make
sure
we
get
a
nice
broad
swath
of
why
lots
of
invitations
might
be
a
great
idea
and
and
certain
deep
dives
and
parts
of
that
yeah.
C
Maybe
I
should
maybe
I'll
quickly
jump
in
here.
Just
to
let
folks
know
that,
like
ipfs's
ipfs
camp
is
happening,
I
know
they're
active
on
working
on
the
website.
This
is
going
to
be
in
amsterdam,
july,
14th
or
17th.
I
believe
some
more
like
public
comms
will
be
happening
soon.
I
know
they're
like
event.
Marketing
side
is
heavily
engaged
in
terms
of
having
secured
venues,
etc.
It
sounds
like
last
week,
or
this
folks,
like
juan
and
molly
and
mosh,
were
getting
involved
from
like
starting
to
set
up
some
program
structure.
C
Obviously
I'm
sure
they're
going
to
be
coming
to
a
lot
of
folks
in
this
call
for
help
in
that,
but
just
want
people
to
know
like
it
is
happening.
There
is
momentum,
building
behind
it
and
hopefully
that
will
become
public
here
quite
quite
soon
and
expect
more
to
come
in
terms
of
what
that
what
that
looks
like-
and
this
is
you
know,
some
of
us
got
to
talk
with
juan
on
monday,
you
and
as
he
was
emphasizing,
this
will
be
different
than
the
ipfs
camp
from
a
few
years
ago.
C
A
few
years
ago,
was
a
little
bit
more.
It
sounds
like
more
workshoppy.
This
is
more
about
like
creating
a
gathering
space
for
you
know,
providing
the
connection
point
for
different
people
to
be
able
to
go
deeper
into
various
tracks
of
conversation
and
design,
etc.
So
it's
at
least
for
a
lot
of
people
in
this
room.
It's
not
going
to
be
as
heavy
on
you
know,
educating
and
like
doing
workshops
for
people
but
more
creating.
A
Cool
all
right
there,
as
many
of
you
may
be
aware,
there
is
a
bitswap
1.3
spec
up
there
for
a
little
while
and
there's
a
few
points
that
seem
like
a
little
contentious,
I'm
wondering
if,
especially
for
those
who
have
reviewed
it,
if
we're
like
at
a
stage
or
we
feel
like
yeah
we've
resolved
most
of
the
we've
resolved
most
of
the
things,
and
probably
we
can
just
let
people
start
implementing
and
we'll
see,
whoever
implements
like
first.
A
D
What's
the,
I
think,
the
last
point
of
attention
that
was
there
for
me
was
the
format
like?
What's
the
there
were
a
lot
of
comments?
So
what's
the
like
latest
thinking
of
like
like
kind
of
like
way
you
landed
on
there,
so.
A
Basically
there's
two
like
schools
of
thought
around
how
we
want
to
like
label
the
tokens
either
it's
just
the
tokens
or
bytes,
or
if
the
tokens
are
prefixed,
with
a
magic
number
in
the
code
table
and
and
then
you
put
whatever
your
bytes
are
afterwards.
A
I
I
think
I'm
kind
of
with
with
steven
here
that,
having
like
the
magic
number
in
front
makes
it
easier
to
like
glue
different
different
token
systems
together
without
having
to
worry
about
how
to
disambiguate
or
like
accidental
collision
kinds
of
things
yeah.
If
people
have
if
people
have
big
problems
with
that,
like
I'm,
I'm
open
to
to
revisiting,
but
like
I
don't
know,
I
guess
the
the
multi-formats
project
is
largely
for
the
low
cost
of
a
few
bytes.
You
know
what
your
data
is,
and
this
feels
like
a
reasonable
place
for
that.
D
It
could
have
added
up
very
quickly
if
you
send
more
than
one
token
and
you
have
to
prefix
every
token
not
like
I
guess
right,
and
so
if
I,
if
I
have
to
use
multiple
tokens
and
it's
like
I'm
worried
about
the
overhead,
like
my
token,
is
my
just
like
totally-
let's
say
my
token
is
64-bit
number
and
I'll
have
to
put
another
64-bit
number
in
front
of
my
toughbook
and
I've
doubled
my
token
side
just
to
disability.
A
Well,
it's
probably
like
a
couple
of
a
couple
of
bytes,
because
if
you
use
the
same
token
repeatedly,
then
it
gets
like
cached
and,
like
the
header
there's
like
a
like.
Instead
of
putting
the
tokens
repeatedly,
we
have
like
a
place
where
we
put
all
the
tokens
and
then
we
have
like
indices
to
point
to
them.
A
A
Yeah
yeah,
that
would
be
that
would
be
like
real,
slow
there's.
A
couple
other,
like
I
guess,
related
small
things.
So
one
is,
I
think,
I'm
inclined
to
you
know
help
out
the
pyrgos
folks
who
started
on
this
earlier
and
just
skip
a
few
token
skip
a
few
protobuf
identifiers
so
that
we
don't
conflict
with
anything.
D
Yeah,
let's
be
nice
to
people
who
use
this
stuff.
I.
A
B
A
A
If
we
want,
is
I
kind
of
want
to
add
an
area
where
you
can
say
send
with
your
your
want
a
I
want.
I
want
this
block
assuming
that
it's
this
big
otherwise
tell
me
it's
like
too
big
or
something
basically
allow
me
to
like
control
the
size
of
the
response.
If
I
know
how
big
the
block
is,
if
I
have
an
idea
of
how
big
the
block
is
supposed
to
be
there's
sort
of
like,
I
have
some
reasoning
behind
that
that
I'll
write
up
when
when
I
can,
I
can
get
to
it.
A
We
can
talk
about
it
more,
but
I
don't
want
to
eat
up
all
the
time
here.
So
if
we
have
like
extra
time
at
the
end,
we
can
talk
about
that.
But
that's
the
only
thing
I
can
see
maybe
wanting
to
change,
but
it
could
also
just
be
another
protocol
bump
later
so.
D
You're
one
of
I
was
wondering
about
is
that
it
is
token-
and
this
is
probably
a
larger
discussion-
I'm
happy
to
do
for
this,
but
I
do
want
to
mention
at
least
is
token
the
right
abstraction,
or
do
we
actually
just
want
to
add
a
general
metadata
field
which
is
much
more
like
here,
could
be
various
things,
especially
if
we
already
prefixes
with
a
magic
number.
It
could
be
prefix
magic
number,
your
authentication
token,
but
now
this
is
more
explicitly
like
arbitrary
metadata
that
higher
level
protocols
can
use.
A
I
yeah
we
should
look
into
a
little
bit.
I
think
that
it
it
can
act
as
sort
of
arbitrary
metadata
if
you'd
like
it
to
yeah,
but
oh
yeah
russell's
point
it's
arbitrary
until
until
people
start
relying
on
it.
A
So
that
way
like
doing
normal,
easy
bit
swap
things
is
easy
and
then,
when
you
want
to
do
like
fancy
bit
swap
things,
then
you
have
to
add
in
like
oh
yeah,
which
of
these
tokens
do.
I
have
support,
for
maybe
we
run
into
problems
later
where
we
want
to
have
ways
to
like
have
something
like
identify
where
I
can
ask
you
like
which
of
these
like
extensiony
things?
A
Do
you
support,
but
we
can
maybe
cross
that
road
when
we,
when
we
get
there,
if
people
start
wanting,
it
then
we'll
add,
we
can
add
a
separate
side,
a
separate
way
of
asking
in
bitswap
like
what
do
you?
What
extensions
do
you
suppose
what.
A
A
A
Be
useful:
well,
while
we're
on
all
around
specs,
I
guess
two
other
things
so
the
reframe-
I
don't
know
if
this
was
done
last
time,
but
the
reframe
spec
is
merged,
which
basically
is
just
defining
it's
a
protocol
that
will
help
us
with
some
like
request
response,
like
building
request
response
protocols
or
having
request
request
response
methods,
mostly
we're
gonna,
we're
starting
off
using
it
for
like
content,
routing
types
of
requests
like
how
do
I
have
an
api
that
sort
of
abstracts
out
a
lot
of
the
things
that
dht
does
for
you,
so
that
we
can
make
it
easy
to
plug
in,
like
you
can
use
a
dht
or
use
the
index
or
network
or
use
whatever
else
you
want
by
just
having
like
here
is
an
api
that
lets
you
do
this,
there's
a
there's
a
pr
to
that
now
to
add
support
for
peer
records,
as
opposed
to
just
like
provider,
records
and
ips
records,
and
once
we
have
that
you
should
be
able
to
build
a
gateway
that
has
like
the
content.
A
Routing
system
live
out
here
and
just
uses
this
this
protocol
to
communicate
between
them,
and
then
that
thing
could
include
all
of
your
grossness
in
there.
You
can
be
like
oh
I'll
check
the
dht
and
I'll
check
the
indexers
and
I'll
check
the
bittorrent,
dht
and
I'll
check.
A
You
know
a
bunch
of
other
random
places
and
I
will
collect
that
data
and
send
it
back
to
you,
which,
which
could
be,
which
could
be
very
nice.
A
Oh
and
and
of
course,
there's
some
issues
have
been
raised
in
the
repo
that
some
friendly
folks
trying
to
clean
things
up,
and
I
think
we
should
do
what
we
committed
to
last
time,
which
is
remove
all
of
the
old
cruft
and
and
start
again
with
things
that
are
actual
specs
for
things.
We
actually
want
people
to
implement.
D
Yeah
speaking
of
actual
specs,
just
briefly,
I've
been
working
through
unix.
Recently,
the
spec
is:
don't
read
the
spec,
it's
not
correct,
it
does
not
tell
you
what
it
actually
happened.
I
didn't
want
an
ipv4
specs.
I
started
the
document
to
collect
all
the
knowledge
from
people
of
like
how
does
a
unix
office
actually
work
which
I'll
post
at
some
point.
It
is
not
a
spec.
I
don't
think
there's.
It
makes
a
lot
of
sense
to
write
a
spec
actually
for
this
because
there's
like
well,
it
happens
that
go
ipvs.
D
Does
this
thing
x
and
we
just
need
to
support
it?
It's
like
okay.
I
don't
know
if
you're
going
to
call
this
a
spec,
but
it
should
be
documented.
It's
what
I'm
trying
to
do
with
this
document,
which
hopefully
makes
make,
will
make
it
easier
for
other
folks
in
the
future
and
also
be
a
good
reason
why
we
want
to
deprecate
it
eventually.
A
Yeah,
I
think,
having
that
would
be
be
really
nice.
It
will
also
we'll
have
a
they'll.
Let
us
have
a
bit
of
some
space
to
ask
some
folks
like,
like
you,
know,
reba
or
rod,
or
I
I
think
iraqi,
put
up
some
some
things
trying
to
clean
up
a
little
bit
about
how
unix
fs
works
and
like
kind
of
get
us
all
on
the
same
page
as
like,
with
all
of
its
with
all
of
its
warts
and
backwards
compatibility
things.
This
is
actually
unix
fs.
D
It's
like
you,
must
do
acts
or
like
it's
more
of
a
description
of
this
is
what
unix
of
us
does
in
the
wild,
and
if
you
want
to
support
it,
this
the
things
you
have
to
care
about
and
understand,
and
so
I'm
fine
with
it
living
the
specs
repo,
I'm
also
fine
like
having
in
some
other
place
right
now,
I'm
it's
it's
a
notion
where
I'm
just
collecting
information
right
now.
I.
E
Would
still
think
like
it
can
be
a
spec.
We
have
example
of
specs.
That
was
not
not
our
but
like
in
the
technology
space.
It's
happened
often
that
we
have
a
specs
that
is
created
after
the
fact
after
implementation
done,
and
they
still
call
that
respect.
So
I
don't
see
why
it
wouldn't
be
a
spank.
That's
fair.
E
B
C
So
there's
the
there's:
the
parallel
like
unix
fs,
1.5
spec,
that's
out
there,
which
I
know
has
been
getting
some
some
traction
like.
I
assume
that
that
1.5
version
that's
talking
about
adding
some
new
functionality.
It's
not
actually
trying
to
fill
in
the
holes
of
the
things
that
aren't
actually
specified.
That
should
be
yeah,
I'm
not
sure
what.
A
Think
the
it's!
If
you
look
in
like
the
specs
under
like
unix
under
unix
fs,
there's
like
a
bunch
of
stuff
with
metadata
with
like
optional
fields
like
mode
and
m
time,
which
does
not
exist.
Well,
I
mean
they.
They
exist.
They
exist
in
some
implementations
and
not
others
right
right
now.
If
I
it
exists
in
jsipfs,
it
exists
and
go
unix,
fs
node,
there's
a
pr
for
it
and
go
unix.
Fs.
E
A
But
there's
a
spec
for
it
that
says
how
it
is
that
it's
supposed
to
work.
Okay,
I.
A
Sorry,
I
think
the
that
part,
I
think
is
specified,
but
I
I
would
agree
steve,
I
think,
well,
the
metadata
all
the
new
stuff
was
specified.
So
people
know
how
to
add.
The
new
thing
in
the
old
stuff
was
was
not
fully
specified,
so
you
still
sort
of
have
to
be
like
if
I
have
the
oral
tradition
of
how
to
do
the
old
stuff.
This
is
how
I
add
the
new
thing
onto
it
right,
and
so
we
should
clean
up
the
old
things
that
it's
easier
for
for
folks
to
work
with.
A
Yeah,
that's
it
are
there
any
things
people
want
to
mention
about
stuff.
They've
been
working
on
recently.
G
I
guess
I
can
just
mention:
there's
a
recent
release
of
ipfs
desktop
0.20.6.
That's
got
a
new
app
ready
metric,
so
we
can
start
measuring
startup
time,
so
we
can
improve
that.
G
F
I
got
a
quick
announcement
that
we
are
renaming
ipfs.
E
F
D
F
A
E
Issue
is
like
I
keep
interacting
with
people.
I
say
I
because
I'm
a
devil,
but
a
lot
of
we
a
lot
of
people,
think
that
and
they
have
this
mindset
where,
like
it,
doesn't
work
in
go
ipfs.
It
does
not
exist
about
itrs
and
we
want
to
stop
having
people
thinking
that
ipfs
is
go.
Ipss
like
ipfs
is
a
protocol
and
go
ipfs
is
an
implementation,
and
if
we
rename
go
ipfs
to
bannon
ipfs,
hopefully
it
will
be
more
clear,
I'm
not
sure
about
an
idfs
but
well.
E
The
point
is
like
there
are
other
implementation
like
you,
can
import
all
the
packages
and
make
ips
as
yourself
like
apfs
lite,
though
you
can,
if
you
want
to
use
ipfs
with
filecoin,
you
can
use
estuary,
which
is,
and
it
uses
each
share
most
of
the
code
with
google
idfl.
But
still
it's
an
awesome
implementation.
E
We
have
what
people
are
working
on
here
are
doing,
and
we
would
like
to
have
more
reconnection
for
the
other
alternatives
because
like
if
we
don't
do
that,
what
people
think
should
happen
is
like
everything
shouldn't
be
in
go
ipfs
and
go
ipfs.
This
master
binary
is
at
least
two
gigabyte
big
and
support
every
feature
in
the
world
which
we
don't
want
to
happen.
A
Yeah,
I
think,
there's
going
to
be
a
few
things
around
both
like
naming
and
specifications
that
will
will
need
to
happen
to
kind
of
like
decouple
a
lot
of
things
that
live
together.
So,
like
some
examples
of
things
that
I
have
heard,
people
consider
as
ipfs
is
the
ipfs.io
gateway
go
ipfs
the
ipfs
public
dht.
So
if
you
run
go
ipfs,
but
it's
like
on
your
lan,
then
it's
like
not
ipfs
anymore,
somehow
or
which
is
like
super,
not
the
point
in
like
many
ways
right
like
there's.
A
So
there's
like
a
lot
of
those
sorts
of
layers
of
like
things,
people
have
have
conflated
as
as
ipfs
that
it's
hard
to
blame
them
when
they
all
have
the
word
ipfs
in
the
name
right.
So,
but
now
it's
worth
like
making
some
adjustments
to
what
to
all
of
that
like
as.
A
E
A
A
A
little
well
so
lib,
p2p
and
ipld
right
are
are
a
little
different
in
that,
because
they
are
able
to
exist
as
just
libraries
instead
of
as
applications
right.
They
have
like
a
little
more.
They
have
like
a
little
more
room
to
maneuver
and
this
like.
What
are
you
right
like
it
becomes
a
little
more
clear
that,
like
oh
lib
p2p,
doesn't
mean
I
have
to
do
literally
all
of
like.
A
I
don't
have
to
have
quick
and
tcp
and
m-flux
and
yammucks,
and
you
know,
and
noise
and
tls,
and
I
still
have
to
support
the
ancient
secio
thing
nobody's
using
anymore
right.
Like
people
have
some
awareness
that
that's
not
required
right
and
same
with
ipld,
you
don't
have
to
support
every
codec
that
seems
like
imply.
You
don't
have
to
support
all
the
features,
because
you
know
specs
and
adls
didn't
used
to
exist
and
they
were
still
ipld.
A
A
I
tried
to
make
a
codec
recently
that
expresses
that
fits
to
the
ipld
data
model,
which
I
suspect
will
add
to
it,
will
give
a
little
bit
of
like
have
a
little
bit
of
friction
and
result
in
some
conversation
with
the
with
people
interested
in
ipld,
because
what
is
the
data
model
seems
to
still
be
like
a
little
bit
in
debate.
A
A
We
should
be
looking
into
for
how
we
want
how
we
want
to
describe
and
interact
with
that.
D
I
think
I
think
the
important
part
that's
actually
like
my
sense
there,
that
what's
much
more
important
is
to
figure
out
the
relationship
of
like
how
much
fbld
is
required
for
you
to
be
called
ipfs,
because
I
I
lean
on
the
like
very
little
side
of
things
but
like
because
I
think
that's
important,
because
if,
if
that
relationship
is
very
very
simple
and
like
there's
not
a
lot
of
finding,
then
we
are
much
freer
to
a
have
disagreements
about
what
I
build
ideas
and
also
experiment
like
whether
it's
the
right
thing
to
do
in
ipld,
and
these
can
all
be
implemented
in
ipfs
implementations
but
nobody's
like
oh
you're,
not
implementing
the
right
subset
of
iple.
G
A
Yeah,
I
will
I'll
share
more
with
folks
here.
If
anyone
wants
to
is
interested,
I'm
trying
to
write
up
some
docs
that
are
trying
to
like
take
a
stab
at
how
we
want
to
describe
what
ipfs
is
or
what
is
required
to
be
an
ipfs
implementation,
because,
like
depending
on
how
much
you
want
to
push
it
right
like
if
I
say
it's
just
content
addressing
you
could
argue
that,
like
utorrent
is
an
ipfs
node
because,
like
you
can
give
it
an
info
hash
and
then
it'll
download
a
thing.
E
A
E
A
Maybe
maybe
not
but
like
depending
on
how
it
is
that
we
like
we
should
have
an
answer
to
that,
though
I
think
right
I
feel
like
that
should
be
like.
It
should
be
something
that,
from
like
a
brand
or
communicate
like
community
unification
perspective,
we
have
like
some
stance
on
right
right.
A
Not
is
it
not
ipfs
because
it's
using
it's
just
using
like
a
shot,
one
that's
implied,
but
if,
like
I
put
the
magic,
the
magic
incantation
of
like
you
know,
f,
f,
zero
one.
You
know
six
three
in
front
yeah,
you
know
six
three
one
one
one
four,
then
then
it
becomes
ipfs
like
is,
does
the
magic
incantation?
Do
it.
D
B
D
I
I
want
to.
I
want
to
note
one
very
interesting
problem
that
I
ran
into
yesterday
when
talking
to
jimmy
about
work,
and
that
is
that
content
addressing
doesn't
mean
hashing
bites,
necessarily
which
it
does
currently
in
all
models
of
ipld
ipfs,
at
least
in
implementations
and
most
specs
as
well.
D
D
E
D
But
it
still
requires
to
you
work
through
with
bytes,
but
the
important
part
is
that
you
copy
the
bytes
well
yeah,
but
it's
bites.
The
point
is
the
hash
is
defined
over
bytes
and
look
how
okay
find
over
fuel
elements,
which
means
you
have
the
same
hash
for
different
bytes,
because
you
don't
care
about
the
underlying
representation.
You
care
about
the
content,
which
is,
to
a
certain
extent,
actually
much
closer
to
content,
addressing,
whereas
with
ipfs
today
actually
does
is
bike
addressing
which
is
which
I
would
hope
that
we
can
resolve
this.
D
D
Yeah,
but
there
are
applications
and
lurk
is
one
of
them
that
runs
into
the
problem
like
this
is
actually
bad
for
them,
because
they
want
different
fight
representations
depending
on
the
situations,
and
they
want
to
be
addressed
by
the
same
hash,
because
there's
no
point
in
rehashing
things
because
they
have
to
have
very
expensive
hash
range.
But
I
wanted
to
bring
that
up
when
we
think
about
like.
Where
do
we
draw
the
line?
A
Yeah,
I
think
I
agree
to
some
extent
right,
like
even
right
content
addressing,
like
you,
wonder
it's
like
a
high
level
address
it
by
by
what
it
is,
a
hash,
isn't
necessarily
isn't
really
what
it
is.
A
hash
is
a
summarized
description
of
maybe
what
it
is
right
and
so
we're
sort
of
like
cheating
a
little
bit.
There
too.
A
I,
I
think,
that's
reasonable,
there's,
probably
some,
whether
it's
it's
names
or
or
documentation
kinds
of
boundaries
we'll
have
to
draw
between
like
the
areas
that
are
sort
of
open
for
us
to
like
try
and
find
out
how
we
include
all
of
these
pieces
and
the
areas
that
are
like
you
are.
You
are
someone
who
wants
to
make
an
ipfs
implementation
or
is
utilizing
actually
best
implementations
which
of
these
things.
Can
you
like
realistically
expect
to
be
able
to
like
plug
into
each
other
right,
and
so
that
that's
like?
A
I
think
some
of
these
pieces
will
have
to
balance,
because
I
definitely
want
to
be
able
to
give
room
to
grow
and
cover
pieces
that
we
don't
currently
cover
without,
but
also
want
to
be
able
to
have
like
people
who
are
implementing
new
things
like
understand.
What's
actually
there,
so
they
can
use
it
or
understand
where
to
go
poking
around
and
what's
going
to
be
like
what's
an
easy.
What's
an
easy
lift
to
like
add
a
new
piece
and
what's
going
to
be
like
a
hard
lift
to
add
a
new
piece.
A
Yeah
so
folks
are
interested
in
the
ipld
and
webassembly
stuff.
I
I
tend
to
whenever
when
I
have
updates,
I
show
them
up
in
the
the
ipf
the
ipld
call
every
couple
of
weeks.
If
I
can
get
this
thing
to
move
along,
it
might
be
really
cool
to
have
it
in
some
ipfs
implementations,
because
then
you
don't
have
to
rewrite
all
the
codecs
and
adls
in
every
language
to
be
able
to
like
represent
stuff
and
move
them
along,
which
would
make
things
pretty
easy
or
much
much
easier
than
they
are
right.
A
Now,
where,
like
you,
have
to
worry
about
the
ecosystem,
lift
time
like
yeah,
you
can
make
any
codec
you
want,
but
then
how
long
is
it
going
to
take
for
it
to
make
it
into
all
of
the
ipfs
implementations,
because
in
reality,
go
ipfs?
Isn't
the
only
one,
and
even
if
go,
ipfs
was
the
only
one
people
update
at
different
rates
yeah
another
one
that
maybe
folks
are
interested
in
is
some
work
we'll
have
coming
up
around
speeding
up
data
transfer.
A
The
the
basic
pitch
is
like
bitswap
is
handy
because
it's
very
easy
to
parallelize.
You
just
sort
of
send
out
blocks
to
peers,
but
it's
unfortunate
because
you
know
if
you
have
a
if
you
have
a
deep
graph,
you
have
to
like
walk
the
graph
with
round
trips
and
if
you
could
have
like,
if
you
could
grab
if
you
could
have
like
an
untrusted
or
not
yeah
an
untrusted,
manifest
of
the
blocks
that
were
in
the
graph
that
you
were
looking
for.
A
You
could
sort
of
decide
how
much
trust
you're
willing
to
give
out
and
basically
accelerate
your
traversal
through
the
graph.
So
I
could
have
like
a
deep
graph
and
actually,
like
a
you,
know,
a
huge
dependently
log
and
download
it
for
multiple
peers
in
parallel
by
growing
my
trust
in
the
manifest
over
time.
A
By
basically,
I
download
a
block
and
then
two
blocks
and
four
blocks
eight
blocks
and
so
like
I'm.
Never
I'm
never
like
taken
advantage
of
by
more
than
say,
like
half
of
the
data
that
I
wanted,
but
it
allows
me
to
do
something
that
you
couldn't
do
with
with
bitswap
or
graphsync,
which
is
be
able
to
like
parallelize
the
download
of
a
deep
graph.
B
Yeah
we've
I've
done
a
bunch
of
research
into
this
area
and
I
think,
if
you
use
you
just
use
the
word
gossip
to
describe
the
manifest
you're
halfway
home
like
it's,
we
wrote
a
protocol
for
query
called
desync
which
generates
manifest
of
dags
and
does
set
intersection
of
between.
In
a
point
to
point
sync,
future
plans
are
eventually
parallelizing
half
the
challenge
we
found
was
actually
generating
the
manifest
super
expensive.
B
You
have
to
touch
all
the
blocks,
so
this
is
where,
like
databases
are
a
good
thing
and
we
don't
have
them
and
go
land
in
a
way
that
is
fast
but
it'd,
be
really
interesting
to
see
how
that
interplays,
with
indexing
work
and
and
have
those
two
ideas,
maybe
two
or
don't
connect,
but
I'm
all
for
res
search.
B
A
Yeah,
I
mean
the
idea
so
there's
like
a
few
things
that
sort
of
come
out
of
this
one
is
like
sometimes
like
the
manifest
will
be.
You
know
yeah,
sometimes
maybe
the
manifest
is
expensive
to
calculate,
but
sometimes
you're
sort
of
doing
it
anyway
right.
Anyone
who's
serving
graph,
sync
request
sort
of
ends
up
doing
something
that
looks
a
lot
like
calculating
the
request
anyway,
and
this
might
be
cheaper
and
you
could
because
selectors
are,
are
reproducible
and
deterministic.
A
You
could
like
cache
those
results
if
you
wanted
to
as
well
yeah,
which
which
may
be
maybe
useful.
Another
thing
which
I
would
I'd
like
to
see
is
like.
If
this
thing
works
out
well,
then
somewhere
else
you
can
start
pushing.
It
is
a
proposal
I
I
had
last
year
around
being
able
to
download
like
large,
shot
two
blocks
and
incrementally
verifiable
way,
because
that
thing
looks
an
awful
lot
like
downloading
a
large
linear
graph,
and
that
would
be
very
easy
to
cache
manifest
about
because
you'd
be
like.
Oh,
I
have
a
block.
A
That's
super
big.
I
should
just
pre-calculate
the
manifest
and
start
it's
probably
pretty
small,
compared
to
the
size
of
the
block
and
it's
something
people
are
going
to
ask
for
a
lot.
So
it's
like
a
much
it's
like
sort
of
in
some
ways,
an
easier
version
of
the
problem
from
like
a
manifest
caching
and
finding
perspective.
D
A
And
you
may
find
uses
for
both
of
them
right
so
like,
for
example,
if
I
was
doing
if
I
wanted
to
do
some
like
unix
fs
stuff
and
get
things
quickly,
maybe
I
would
get
unexcess,
maybe
not
a
great
example,
because
the
if
the
trees
are
balanced,
they're,
actually,
not
so
bad,
but
like
maybe
I
want
to
use
something
like
that.
Looks
like
something
like
graph
sync
to
ask
for
the
first
x
bytes
of
the
unixfs
file
and
then
use
the
manifesty
approach
and
bitswap
for
the
rest
of
it.
A
E
A
E
E
I
believe-
and
if
you
swap
this
so
like
you
have
the
data
first
then
the
links
you
could
just
put
the
first,
like
whatever
2k
of
data
in
the
root
file
and
then
have
the
links
your
time
to
first
buy.
It
will
be
literally
the
time
to
download
the
first
block
because
you
download
the
first
block.
You
already
have
the
first
2k
of
data
and
you
can
do
that
for
all
the
routes
and
so
for
the
time
to
first
buy.
It
is
like
always
kind
of
good,
so
the
first
2k
is
pitching
one
block.
E
The
next
2k
is
switching
one
block,
plus
one
block,
because
you
already
had
two
thirds
the
first
2k
and
then
like
quickly.
It
will
reach
the
least
block.
I
I
guess
you
wouldn't
actually
sleep
the
data
field.
It
will
add
a
new
field
like
pre-data
or
something
like
that
for
backward
compatibility,
but.
A
A
We
don't
even
get
pretty
close
in
the
sense
to
like
you
can
do
like
a
little
bit
of
you
can
like
combine
a
little
bit
of
like
the
trickle,
dag
approach
and
the
balance
tag
approach
to
kind
of
get
the
first
few
bits
the
first
little
bit
easier
and
the
less
than
the
rest
of
it.
More
balanced
understanding.
B
If
I
just
take
correctly,
that's
actually
what
car
v2
is
doing,
there's
support
for
indexes,
which
we
should
absolutely,
if
you're
talking
about
manifest
dean,
that
that
work
needs
to
be
synced
with
the
index
work
in
carvey.
Do
I'm
pretty
sure
it's
just
like
a
generic.
We
support
indexes.
You
can
do
whatever
you
want,
but
they
do
header
payload
blocks
indexes
at
the
end.
If
I'm,
if
I'm
not
mistaken,
I'm
basing
this
off.
A
Yeah,
it
seems.
A
G
D
A
I
I
would
I
I
feel,
like
the
general
thing
that
you'll
run
into,
or
you
may
notice,
with
with
car
v2,
is
that,
like,
as
a
way
of
there,
was
a
particular
problem
that
was
trying
to
be
solved
and
they
wanted
to
enable
like
backwards
compatibility
with
some
of
the
car
v1
stuff
as
much
as
possible,
without,
like
rewriting
everything
that
being
said,
having
other
like
file
formats
for
describing
collections
of
blocks
seems
highly
reasonable.
There
have
been
some
that
are.
A
There
are
ones
like
I
want
to
do
if
I'm
interested
in
like
files
and
unix
fs.
Maybe
I
want
one
where,
like
all
the
bytes,
it
looks
like
the
file
store
in
in
like
in
go
ipfs,
where,
like
all
the
all
the
bytes
live
here
and
then
the
index
that
tells
you
the
cid
and
which
byte
offsets
they
are
lives
over
here,
so
that
I
can
leave
alone.
A
I
can
like
put
this
thing
like
in
s3
and
let
you
read
the
byte
offset
range
and
that's
still
the
file,
but
like
the
index
part
for
if
you
wanted
to
do
verifiable,
like
verifiably
downloading
the
file
the
index
lives
over
here,
and
you
just
sort
of
you
can
grab,
you
can
grab
one
if
you
want
it
untrusted
and
you
grab
them
both.
If
you
want
it,
if
you
want
it
verifiable
right.
B
A
A
One
of
the
nice
things
that
we
will
have
now
is
like
a
way
to
be
able
to
create
new
types
of
provider
records
without
a
full
network
upgrade
which
is
like.
Oh
thank
god.
A
Finally,
right
because
the
problem
with
like
the
the
some
of
the
like
the
dht's,
are
very
useful,
but
because
they're
these
like
organisms
they
have
to,
like
you,
have
to
figure
out
how
they're
going
to
like
evolve
right,
especially
with
people
updating
at
different
speeds
and
all
of
that
with
the
with
the
indexer
system
and
with
the
fact
that
the
reframe
allows
for
like
different
types
of
records.
A
We
can
start
adding
more
like
if
we
come
up
with
good
ideas
for
like
new
types
of
records
that
we
should.
That
should
be
there,
whether
they're
to
support
new
protocol
types
or
whether
they're
to
support
like
advertising
more
data
than
just
a
block
like
advertising.
Some
graph
information
right,
those
those
all
seem.
Those
are
like
much
more
now.
Like
without
within
the
realm
of
possibility
than
they
were
beforehand,
because
it's
like
faster
to
iterate
on
that-
which
I
think
will
be
like
quite
promising
for
us.
A
All
right,
we
got
a
few
minutes
left.
Anyone
else
have
anything
on
their
on
their
mind.
B
F
B
B
I
think
that
we
should
make
somebody
should
that
I
mean
whatever
work
you're
doing
on
the
index,
manifesting
stuff,
I'd
love
to
hear
about
it
and
I'd
love
to
make
sure
that
it
syncs
up
with
car
v2
indexes
so
that
we
just
don't
let's,
let's
not
make
more
index
specs
if
we
can
avoid
it,
unless
we
have
a
good
reason
to
so
I'd
love
to
sync
up
and
make
sure
that
that
conversation
is
at
least
had,
and
then
there
was
another
something
else
that
came
out
of
here.
B
B
B
My
other
question
is
just
like
advancing
work
on
the
actual
ipfs
specs
is
that's
happening,
async
on
github
like
how
do
people
get
involved
in
that.
A
If
you,
if
you
have
a
spec
that
you
you
either
want
to
like
clean
slate
and
throw
out
the
old
one
or
or
you
have
something
else
like
just
submit
a
pr,
if
you
submit
a
pr
for
the
unix
fs
spec
before
it
is
before,
we've
moved
everything
into
like
an
underscore
archive
folder,
that's
fine
whoever's
in
charge
of
doing
the
move.
Everything
into
an
underscore
archive
folder
will
have
to
do
some
rebasing
to
help
you
out.
So.
A
I
don't
feel
bad
if,
like
there's
stuff,
that's
that's
like
that's
missing,
because
right
now
you
have
some
specs
there
that
are,
some
of
them
feel
are
sort
of
like
feels
bad
specs,
like
the
repo
file
system.
Spec
is
a
feels
bad
spec
right
so
like.
If
we
can,
we
can
go
ahead.
We
just
call
it
that
underscore
if
it
feels
bad.
A
Let's
see
yeah
and
for
bitsoft
1.2,
I
guess
we
seem
to
have
agreement
that
we're
just
gonna.
We
I'll
comment
on
that
that
we're
gonna
leave
things
basically
as
they
are,
and
first
implementer
that
comes
around
and
has
runs
into
problems.
Please
report
back
and
we'll
see
if
we
want
to
make.
D
A
Oh
yeah,
I
I
got
distracted
gus
made
a
bunch
of
good
comments.
I
want
to
merge
all
of
his
comments
and
then
actually
do
that.
But
yeah.
That's
that's!
That's
on
me.
Sorry.
A
Mean
there
are
some
I,
I
guess
worth
calling
out
for
the
original
bit
slop
spec.
There
is
one
thing
that
I
did.
That
was
maybe
a
little
bit
controversial,
which
is
that
in
specifying
some
of
the
and
bits
and
specifying
some
of
like,
like
bitswap
1.2
1.1
like
I
removed
some
of
the
fields
that
are
no
longer
necessary,
despite
the
fact
that
like
go,
bitswap
will
happily
process
them
right,
weird
like
given
that
I
have
given
that
we've
moved
around
where
the
blocks
are
and
that
they're
not
all
assumed
to
be
dag
pb
anymore.
A
A
A
Is
which
is
fine?
We
can
keep
like
the
protobuf
feel.
The
probe
of
numbers
are
free,
we
can
keep
like.
We
can
just
make
new
ones
and
leave
the
old
ones
alone,
like
we're
going
to
do
what
what
we're
doing
for
you
know
the
pirgos
folks
but
yeah.
I
just
wanted
to
call
out
that.
I
I
made
that
change,
which
I
guess
seems
natural,
but
I
guess
there
was
no
spec
there
before
specifying
it,
but
if
you
had
imagined
the
spec
previously,
it
may
not
have
looked
like
that.
D
D
Okay,
cool!
Oh,
I
have
a
general
question:
it's
well
without
it.
Maybe
people
won't
know
right
now,
I'm
trying
to
figure
out
how
much
value
is
there
in
supporting
bitswap,
1.0
and
1.1
in
a
new
implementation
like.
A
I
don't
know
it's
a
good
question.
I
think
we
have,
let's
see
if
I
can
pull
up
some
dashboards,
that
explain
like
protocol
that
show
like
which
protocols
are
advertised
across
the
network.
I
know
I
have.
I
have
some
some
other
folks
who
have
a
bunch
of
folks
have
written
various
dht
crawlers,
who
can
like
show
a
bunch
of
that?
C
A
A
Almost
everybody
has
bitself
1.2,
so
I've
like
this
sample
that
I'm
seeing
here
I've
got
like
you
know
at
some
point
today
there
were
this
crawl
saw
50
like
about
you,
know,
51k
peers
that
spoke
bit
swaps,
nor
like
no
no
version
through
1.1
and
49.6
that
did
1.2.
So
if
you
did
1.2
only
you're
losing
like
a.
D
A
But
it's
good,
we
should.
We
should
also,
like
you
know,
call
them
we'll
have
to
see
how
this
goes,
because
people
use
ipfs
in
a
variety
of
ways
and
the
networks
aren't
all
attached
or
crawlable
right,
but
if
we
can
get
out
some
like
public
metrics
that
show
support
of
various
of
these
protocols
that
also
make
it
easier
for
implementers
to
figure
out
like
what
do.
I
even
have
to
implement
right,
which
I
think
yeah
will
help
take
some
of
the
mystery
out
of
making
a
new
implementation
right.
Yeah.
D
A
Let's
put
that
as
an
action
item,
we
should
find
see
if
we
can
get
a
place
to
make
public
and
maybe.
D
We
can
just
have
the
public
listeners
like
these
protocols
are
kind
of
like
deprecated
or
like
like
it's
fine.
You
know
in
implementations
that
do
not
support
it
like
it
won't
break
badly.
Maybe
like
have
some
process
for
that.
The
probe.
B
Lab
folks
have
been
putting
out
public
stats
every
day,
so
giannis
and
others
yeah.
I'm.
A
E
The
name,
but
it
should
be
easy,
dad
yeah.
D
D
So
I
was
just
wondering
what's
what's
this
like?
What's
your
current
state
of
that,
like.
F
Yeah,
so
I
got
like
a
bunch
of
disjoint
notes
and
generally
I
just
shut
down
everything
for
a
day
and
compile
it
after
0.13
chips
right
now,
just
trying
to
unlock
that
so,
hopefully,
and
and
and
yeah.
That
would
be
just
pr
against
specs
repo,
I
think,
hopefully
after
we
clean
it
up
clean
slate,
I
guess.
D
A
Yeah
we
also
have
so
there
are
a
few
things
that
I
call
that
about
the
0
13
release
that
may
be
of
interest.
One
is
that
it,
it
has
hole
punching
the
other.
A
Yeah,
the
other
is
like
enabled
by
defaults,
which
yeah
and
with
like
discovery
for
for
peers.
That
will
let
you
do
relay
we'll
do
reeling
for
you
to
help
you
with
the
hole
punching.
There
were
a
few
gateway
api
changes
that
are
there.
No
some
notable
ones
include.
I
can
ask
for
a
car
file
without
any
api
v0
nonsense,
which
surely
nobody
making
a
new
gateway
implementation
will
want
any
of
the
api
v0
stuff
if
they
can
avoid
it.
What.
F
D
G
A
Some
of
the
there
are
some
pieces
of
api
v0
that
are
useful
that
are
not
usable
from
gateways.
Yet
some
examples
include
before
this
release
there's
getting
out
car
files.
This
one
are
individual
blocks.
Another
one
is
like
exporting
unix
fs
directories.
A
A
So
there's
like
a
few
of
these
things
that
we
probably
want
to
add
into
the
gateway
spec
to
make
things
happy
for
people,
but
we
want
to
make
api
v0
not
required
for
anyone
else
who
wants
to
make
a
gateway,
yeah
and
maybe
even
have
like
if
there's
enough
functionality
for
anything
popular
have
like
here's,
the
nginx
rewrite
that
will
let
you
like
rewrite
anyone
who's
using
the
old
thing
to
like
translate
it
into
the
new
thing
for
you,
yeah.
B
A
All
right,
well
until
next
time,
if
you
have
comments
around
how
this
meeting
could
run
better
for
you
drop
them
either
in
the
bottom
of
this
one
or
in
the
meeting
notes
that
will
be
opened
for
the
next
one,
which
will
be
happening
shortly.