►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2020-11-09
Description
A weekly meeting to sync up on all IPLD (https://ipld.io) related topics. It's open for everyone and recorded. https://github.com/ipld/team-mgmt
A
Welcome
everyone
to
this
week's
ipld
sync
meeting
it's
november,
the
9th
2020
and
as
every
week
we
go
over
the
stuff
that
we've
worked
on
the
past
week
and
then
discuss
any
open
issues
we
might
have
and
yeah.
I
start
with
myself.
So
there's
currently
there's
a
lot
of
stuff
happening
on
the
rust
side
of
things.
A
So
now
there
was
a
new
release
on
rust,
multi-base,
which
can
now
be
compiled
with
no
standard,
which
basically
means
without
the
standard
library
and
that's
mostly
for
like
smaller
systems
and
so
on,
and
it's
always
a
nicer
feature
but
kind
of
complicated
to
get
it
right
in
rust
and
that's
now
possible
for
multibase
and
it's
already
possible
for
rust,
multihash
and
wpr
for
pr4cid
is
also
in
there.
A
So
soon,
like
the
low
level
parts
will
all
work
without
the
standard
library
which
is
pretty
exciting
and
then
there's
a
new
rastmodus
version
upcoming,
which
is
based
on
the
review
from
the
libp
to
pr
and
regular
viewers
might
remember
that
I
opened
a
lib
p2p
issue
a
long
time
ago
and
hope
to
get
feedback
for
this
vr.
So
I
can
make
those
changes
to
rust
and
multicast
and
then
do
a
release.
A
This
didn't
work
out,
so
I
did
the
release
and
now
I
do
another
breaking
release
with
the
feedback
I
got,
which
I
hope
to
get
over
here,
but
it
really
doesn't
matter
that
much.
It's
not
it's
not
like
a
super
hard
breaking
change,
but
it's
just
makes
things
easier
and
better
and
actually
more
similar
to
previous
versions.
So
if
people
actually
upgrade
from
the
old
version
to
this
that
new
version,
it
will
be
smoother
than
upgrading
to
the
current
version-
yeah-
that's!
A
Hopefully
I'm
done
this
week
and
then
I
also
refined
the
there's
an
issue
open
about
invariance
for
hyperlink
codex.
A
We've
discussed
it
a
bit
and
it's
all
in
the
issue,
and
the
short
version
is
that
I
proposed
a
new
wording
for
this-
that
basically,
if
we
have
codecs
like
dexymore
or
deck
protocol
buffers
that
whatever
uan
code
should
also
be
able
to
be
decoded
by
a
stock
and
a
decoder
of
the
corresponding
codec,
in
this
case
seaport
or
protocol
buffers
anyway,
it's
all
in
the
issue.
You
have
feel
free
to
chime
in
there.
A
So
yeah,
that's
all
I
did
in
the
in
the
april
d
world
and
next
on.
My
list
is
rod.
B
And
when
I
find
my
button
there
we
go
so
too
many
windows
open.
C
B
Oh
hang
on:
am
I
being
hurt?
Okay,.
B
Wrong
microphone,
this
one
should
be
better.
So
last
week
was
two
main
things.
The
new
javascript
card
library
is
done
thoroughly
so,
and
I
just
need
michael
to
publish
it
since
michael
holds
all
the
keys.
So
michael,
can
you
please
do
that
and
it's
got
docs
and
it's
got
the
whole
type
skip
typescript,
verification,
stuff
and,
most
importantly,
it's
got
some
ideas
about
a
new
block,
storage
interface
that
should
apply
to
other
sources
of
blocks
so
and
and
this
the
way
it's
done
is
very
separated
into
function.
B
And
if
you
wanted
to
iterate
through
the
blocks,
then
you
would
go
and
go
for
another
one,
and
these
things
could
potentially
be
combined
with
an
interface
that
like
if
your
blocks
were
in
like
level
db,
that
had
easy
access
to
all
of
these
functions.
All
these
functions,
then
you
just
have
one
thing
that
combines
them
all,
but
this
this
splits
the
functionality
up,
so
that
when
you
have
these
block
stores
that
have
various
limitations,
you
will
only
get
interfaces
that
work
for
them.
B
So
that's
a
theory,
but
since
this
is
the
first
one
really
using
a
new
style
block
interface,
that's
it's
really
a
lot
of
theory,
but
it
works
well
for
this
and
it's
you
know
when
you're
like
working
with
car
files,
you
tend
to
have
just
one
style
of
interaction
in
mind
when
you're
doing
it,
if
you
just
want
to
iterate
through
the
whole
lot
or
if
you
just
want
to
fetch
individual
blocks,
that
tends
to
be
the
two
styles
when
you're
reading
car
files.
B
So
that's
that
I
did
some
more.
I
got
a
photo
library
that
extracts
js
doc
into
and
pulls
it
into
a
section,
and
you
read
me-
and
I
did
a
bit
of
work
on
that
during
this-
to
make
it
better
at
handling
some
of
the
newer
typescript
style
annotations
and
I
tweaked
the
output
a
bit
more,
a
little
bit
less
noisy
and
a
bit
easier
to
read.
B
I
think
so
the
readme
of
js
car
has
that
style,
api
documentation
and,
lastly,
the
pro
request:
three
and
two
nine
on
specs
repo,
which
has
the
file
coin
forms
of
data
forms
that
we've
been
talking
about
pulling
out
and
there's
there's
two
big
things
in
well:
there's
a
bunch
of
big
things
in
there
there's
the
main
chain,
and
that
also
includes
the
adls.
B
This
is
the
hampton
the
amt
which
are
sort
of
mixed
up
with
the
data
and,
as
eric
pointed
out
that
they
all
start
at
at
the
root
of
a
block.
So
they
you
link
to
an
adl.
They
don't
embed
them
in
something
else,
but
the
values
get
embedded
in
adls
in
most
cases,
in
some
cases
they
they
link
out,
but
in
most
cases,
they're
embedded
values
in
line.
B
We
need
to
find
a
way
of
compacting
that
so
that
it's
not
as
verbose,
but
we
don't
lose
that
information
about
the
block
layout.
I'd
really
like
to
be
able
to
still
show
what
is
in
all
of
the
raw
blocks,
if
you
were
to
read
them
as
raw
blogs
and
then
step
up
a
level
to
say.
Okay,
if
you
read
these
things
as
adls,
then
this
is
what
you
would
see
so
multiple
ways
of
drilling
down
into
the
details.
So
we've
got
to
figure
out
how
to
do
that.
B
The
second
thing
it
contains
is
there's
a
second
dock
which
has
messages
now
the
messages
get
embedded,
they
get
they
get
encoded
as
seaboard
and
then
embedded
in
a
bytes
field
in
one
of
the
blocks,
which
then
gets
encoded
as
taxi
board.
That's
just
how
messages
work
so
that
they're
separate
separately
specified
as
these
separate
things
and-
and
I
see
wills
answered
my
question
today-
that
the
the
returns
from
those
messages
also
gets
encoded.
So
we
probably
need
to
define
them
as
well.
B
So
there's
a
message
in
and
then
there's
a
return
from
it
and
then
there's
differential
between
version,
zero
and
version
two
of
actors,
so
that
needs
to
be
looked
at
and
the
other
thing
that
yesterday
I
realized,
as
I
was
going
to
bed,
that
I've
been
mostly
looking
at
the
master
branch
of
actors
and
and
not
specifically
version
two,
and
so
I
probably
need
to
go
back
and
check
out
version
two
because
they're
preparing,
for
I
know,
version
seven
or
something.
B
So
I
need
to
go
back
and
make
sure
that
I
haven't
referenced
all
this
stuff
on
a
newer
format
that
doesn't
exist
in
the
blocks.
So
that's
a
bit
annoying
anyway.
I
I
pretty
happy
with
this
first
pass
very
verbose,
but
that's
the
chain,
it's
big,
so.
D
I
yeah,
I
just
want
to
add
a
couple
of
things.
The
card
files
that
I
gave
you
do
not
have
the
all
the
returns
from
the
vm
they
did
not
have.
D
The
receipts
would
not
have
currently
a
way
to
export
that
you
will
have
for
sure
by
our
next
meeting,
but
hopefully
way
before
that
you
will
have
a
way
to
get
them
from
a
different
place,
but
they
are
not
in
discover
files,
and
I
have
no
way
to
put
them
in
this
car
file
so
expect
some
dangling
references,
basically,
that
you
cannot
get
to
number
one
number
two,
the
actors
actually
master
always
is
what
they're
going
to
be
tagging
next.
So
it's
not
like
waste
of
work.
E
Yeah
and
it's
worth
noting,
I
think
the
real
issue-
I've
I've
also
run
into
the
same
problem.
Rod
did
when
you
look
at
master
branch
of
actors.
There
are
structs
that
are
not
really
defined.
They'll
like
have
a
type
alias
to
v2
or
v1.
When
you
look
at
the
concrete,
v2
or
v1,
sometimes
they're
also
not
defined,
but
the
comments
are
different
and
actually
define
what
the
struct
is
or
where
it's
going
to
be
at
that
version.
E
So
there
is
value
at
looking
at
the
tagged
versions:
the
the
documentation
weirdly
changes
between
these
tags
in
a
way
that
looking
at
it
is
illuminating.
E
B
I've
been
wondering
if
maybe
actually
doing,
some
work
on
clarifying
stuff,
even
even
little
things
like
when
you're,
when
you're,
sorting
through
messages
and
they're
defined
in
one
order
at
the
top
and
then
they're
shuffled
down
the
bottom.
Like
that's
really
annoying
and
I
keep
on
thinking-
maybe
I
should
go
in
there
and
shuffle
them
and
pull
requested
back.
But
you
know
that's
noise,
that's
useful
for
me,
but
probably
not
useful
for
code
churns.
So
anyway,.
D
And
just
one
more
point:
the
thing
that
you
looked
at
master:
it
will
actually
become
the
next
version
in
by
the
end
of
this
week.
It
will
be
tagged
so
you're
you're,
very,
very
close.
B
That's
the
that's.
The
most
frustrating
part
of
this
actually
is
is
the
versioning,
because
you
have
to
you,
have
to
do
it
deep,
essentially
on
looking
at
the
source
code
side
by
side.
B
What's
changed
and
like
because,
as
will
said,
I
I
don't
have
a
high
degree
of
trust
in
some
of
the
linkages
and
some
of
the
reuse
so,
and
I
think
what
we're
building
will
hopefully
be
help
help
to
be
a
source
of
truth
on
this
stuff.
So
getting
it
right
is
probably
important
on
our
end.
D
Well,
just
to
say
something
positive
to
be
like
completely
out
of
character.
For
me,
we
have
been
live
for
like
four
weeks
now
three
weeks
and
we
had
four
upgrades
of
essentially
the
internal
vm
completely
flawlessly,
so
what
they
built
works
in
terms
of
architecture
and
stuff
like
that,
so
they
got
it
right.
We
got
to.
You
know,
figure
out
how
to
work
with
that,
because
no
other
blockchain
that
I
know
can
actually
just
swap
stuff
like
this
on
on
the
fly,
without
without
anything
important,
so
yeah.
B
Yeah,
it
is
annoying
still
to
you,
have
to
use
chain
height
for
this,
because
we
have
we
do.
We
just
have
no
way
of
signaling
in
our
schemas
that
this
thing
goes
here
or
here
and
trying
to
come
up
with,
like
there's
just
no
way
to
do
unions
of
structs
that
change
in
shape.
B
Like
you
add
a
field
like
we
could
make
it
optional,
but
it's
just
that's
not
actually
what's
going
on
it's
going
to
a
new,
so
I
I'm
that
that
process
is
annoying
and
I
think
it
just
means
we
have
to
we're
going
to
have
to
get
detailed
about
when
you
switch
between
the
different
versions,
the
chain
height
here
then
you're
actually
reading
from
here,
and
that's
pretty
annoying.
B
D
B
And
that
doesn't
help
I
mean
we're
live
so
like
let's
move
on,
but
it's
just
it's
just
frustrating
anyway,
but
yeah,
but
there's
also
other
other
things
that
that
are
interesting
for
schemers.
Like
you
know,
eric-
and
I
have
been
talking
about
this-
there's
places
where
we
just
can't
describe
what's
going
on
like
the
actors,
when
you
jump
into
an
actor's
state,
you
you,
you
can't
define
the
union
because
it's
it's
the
jump
point
that
defines
what
you're
going
to
read
and
and
the
key.
B
B
Okay
and
and
and
preparing
for
an
ideal
future,
has
never
been
a
problem
in
engineering.
Okay,.
B
Okay,
so
so
the
union
is
is
defined
by
something
outside
of
the
jump
point,
and
so
so
in
our
schemas.
We
have
no
there's
multiple
places
in
which
you
can't
link
them
together.
So
you
can't
you
can't
draw
a
graph
like
the
nice
graphql
graphs
that
will's
been
showing
without
some
manual
linking
and
actually
saying
this
pit
piece
connects
to
this.
You
couldn't
take
our
schemas
and
then
just
draw
that
from
the
raw
schemas.
B
We
have
to
have
all
this
additional
metadata
that
describes
how
they
link
what
the
unions
of
the
different
link
jump
points
are,
and
I
I
I
have
been
wondering
if
there's
ways
we
can
extend
the
schema
language
to
describe
some
of
those
things.
I
know
it
makes
eric
a
little
bit
his
skin
crawl,
a
little
bit
to
talk
about
things
like
link
type
hint
unions
or
union
issues
where
you
can
actually
say
this
link,
because
we've
got
a
type
hint
in
our
link,
which
does
help
with
this
problem
of
connecting
blocks
together.
B
If
you
could
extend
that
type
hint
to
say
this,
this
link
could
resolve
to
this
list
of
types
that
would
help.
But
there's
the
versioning
is
another
problem
as
well.
It
would
be
nice
to
have
solutions
to
some
of
these
things
that
help
the
documentation
process,
but
it's
also,
we
have
to
recognize
that
you
know
far
coin's
been
pushing
limits
here
on
stuff
that
you
know,
maybe
maybe
we
have
limits
that
are
different
to
the
far
coin
limits.
B
You
know
we
have
had
recommendations
to
file
coin
in
the
past
that
have
been
ignored
and
we're
sort
of
eating.
Some
of
that
now,
maybe
you
know
we
shouldn't
undermine
too
much
of
our
work
just
to
fit
into
the
decisions
they've
made,
and
this
is
just
an
internal
limitation
so
anyway,
food
for
thought.
F
Cool,
so
my
pull
request
to
revive,
go
multi-code
cut
some
reviews,
so
I
think
we
mostly
agree
on
the
on
the
code
and
what
it
does
on
the
api,
but
then
something
that
I
kind
of
glossed
over
is
the
name
of
the
repo
itself,
so
maybe
go
multi.
Codec
is
not
a
good
repo
name,
so
maybe
it
should
be
co,
multi
formats
mirroring
js
multi
formats.
So
I
added
an
action
item
at
the
top
of
the
dock
to
get
some
decision
on
this
later.
F
I
also
did
some
more
work
on
the
hemp,
so
I
added
a
bunch
of
I
essentially
added
a
method
to
input
a
link,
loader
and
the
store,
and
so
on.
So
now
it
at
least
in
basic
cases.
It
does
know
how
to
load,
links
and
create
new
links
and
so
on,
which
was
pretty
basic
for
a
hand.
F
I
left
a
few
spec
questions
on
slack,
so
I
hope
to
get
a
reply
to
those
soonish,
but
it's
not
urgent.
I
also
synced
with
eric
earlier
today,
essentially
on
you
know.
Up
until
now,
I
was
mostly
working
by
myself
on
stuff
that
I
needed
to
figure
out
and
so
on,
but
now
I've
gotten
to
a
point
where
I
need
to
sync
with
him
and
help
him
land
new
stuff
in
ipld,
prime,
such
as
the
codec
work
that
he's
been
doing,
which
leads
to
the
new
link
interfaces
which
are
going
to
help
me
as
well.
F
And
the
next
thing
I
need
to
do
in
the
adl
is
to
teach
it
how
to
copy
nodes,
because
right
now,
whenever
it
modifies
a
hand
node
it
just
modifies
things
in
place,
which
is
fine
for
the
sort
of
unit
test
that
I
have
right
now.
But
for
a
real
hand,
it
needs
to
copy
things,
and
something
that
michael
mentioned
earlier
is
that
it
would
be
interesting
if,
if
this
atl
supports
the
new
schema,
but
also
file
coin
schema.
F
At
the
same
time,
I
think
it
should
be
feasible.
I
need
to
investigate
a
little
bit
and
if
that's
possible,
he
said
that
something
that
might
be
interesting
to
the
falcon
people
is
to
then
implement
batch
updates,
because
it's
something
they
don't
have
in
the
current
hand.
F
E
Sure
I
have
spent
a
bunch
of
the
last
week
doing
graphql
code
gen
off
of
the
go
ipld
schema
so
from
that
schema,
I'm
now
generating
most
of
a
graphql
server.
That
is
able
to
go
from
that
ipld
data
objects
and
then
create
graphql
queries
and
serve
them
off.
Of
that,
I
can
actually
maybe
share
my
screen
and
show
this
briefly.
E
Possibly
yeah,
so
this
is
a
query.
This
actually
touches
on
a
bunch
of
things.
Rod
was
saying
so
so
let
me
see
if
I
can
say
them,
so
I've
got
the
actors
map.
This
is
the.
This
is
a
hampt
where,
right
now
I
just
let
you
select
an
individual
key
or
object
off
of
it
and
then
head
is
this
implicit
union
where
this
is
actually
a
sid
that
links
to
one
of
a
bunch
of
things?
E
I
updated
my
schema
so
that
I
have
an
implicit
union
here
where
it
gets
one
of
the
concrete
actor
states
off
of
it,
and
that
implicit
union
is
one
that
you
know
when
you
follow
the
sid.
You
get
the
concrete
thing
and
for
whatever
reason,
graphqls
unions
are
essentially
implicit
unions,
so
it
works
totally
fine
here.
The
only
place
where
it
doesn't
really
work
is.
E
If
you
were
then
to
try
and
use
the
schema
as
a
direct
ipld
over
the
data
type
you
would
sort
of
get
ipld
would
get
confused
because
the
data
itself
doesn't
have
the
discriminator
of
which
value
it
is
the
other
one
that
rod
ran
into.
Is
that
when
you
ask
for
the
state
route
of
a
block
before
some
height,
you
got
directly
an
actor's
hand
rather
than
the
stateroot
object,
which
includes
the
version
and
info,
and
so
again
I
had
to
put
in
a
little
piece
of
you
know
shim
for
filecoin.
E
That
says
if
it's
below
that,
what
I'm
going
to
do
is
make
a
synthetic
one.
That's
just
sort
of
in
injected
little
object.
That
says
this
is
a
synthetic
info
state
route
and
and
sort
of
demotes
the
sid
of
the
actor
hand
down
into
where
it
should
be,
so
that
you
get
a
consistent
schema
across
that
transition,
so
that
you
can
always
sort
of
query
these
things.
E
But
the
the
exciting
part
here
is
once
you've
got
that
graphql
is
pretty
happy
where
you
can
say
look
if
this
is
an
actor
I
want
to
get
the
address
if
it
is
a
minor.
I
want
to
do
that
and
then
based
on
your
input.
So
if
I
input
something
that
is
a
an
account
object
in
file
coin,
I
get
its
address,
whereas
if
I
input
something
that
is
a
minor,
so
what's
a
minor.
E
That
one's
a
minor
it'll
instead
tell
me
who
its
owner
is.
So
I
get
different
things
based
on
the
thing,
and
this
union
is
basically
just
working.
So
that's
reasonably
exciting
progress,
and
this
is
all
happening
happening
without
really
much
overrides
at
all
or
any
like
custom
code.
This
is
just.
E
Sorry
zoom
is
being
confusing
just
just
happening
purely
off
of
the
coach,
so
a
little
bit
more
work
to
finish
there,
but
I'm
I'm
pretty
happy
with
how
little
work
had
to
happen.
That's
not
ipld
generic
versus
filecoin
specific
and
then
help
trod
on
some
of
this
crazy
spec.
E
D
Yeah,
nothing
actually
to
report.
I
built
this
last
week,
aside
from
consuming
working.
D
Hopefully,
you
got
everything
for
part
one
taken
care
of
and
in
the
process
managed
to
break
gokar.
Yet
again,
on
top
of
the
issues
the
trad
fix,
there
are
more
short
fields
and
stuff
like
that.
I'm
actually
like
right
now,
while
this
goes
and
I'm
getting
the
test
case
for
it,
because
I
cannot
like
replicate
myself
for
some
reason
and
yeah.
That's
all.
I
have
nothing
exciting.
G
Not
a
ton
to
report
because
I
spent
just
a
bunch
of
time
doing,
review
and
thinking
on
various
stuff
this
week,
I'm
really
excited
about
all
the
falcoin
schematization
work.
We're
really
excited
about
all
the
ham
stuff
that
got
close
to
landing.
G
The
majority
of
the
interesting
tech
stuff
that
I
did
this
work
week
is,
as
we
start
looking
at
using
cogen
more
and
more
and
more
and
more
it's
starting
to
get
to
be
maybe
time
to
take
a
peek
at
the
output
size
and
and
try
to
quantify
it
first
of
all
and
see
if
it's
a
concern
at
all
or
not,
but
like
know
that
confidently
and
then
maybe
see
if
it's
time
to
like
start
improving
things
already,
and
so
I
didn't
honestly
get
very
far
on
this.
G
It
turns
out
to
be
a
big
topic,
but
there
is
at
least
an
issue
opened
up
now
for
the
discussion
on
that
it
tracks
a
couple
of
things
that
I
suspect
are
going
to
be
future
work.
G
And
I
started
taking
a
peek
at
some
of
the
current
size
stuff
and
I
think
I
basically
so
far
just
realized
how
much
more
work
we're
going
to
need
there
right
now
to
try
to
get
a
handle
on
that
is
is
a
very
hands-on
and
somewhat
manual
process.
I
think
it
will
be
possible
to
script
some
tooling
to
help
inspect
well,
okay,
so
inspecting
the
generated
source
code,
textual
output,
size.
Of
course
that's
easy.
G
You
just
like
do
ls.l
right,
so
breaking
that
down
to
give
us
guidance
as
developers
of
this
system
to
see
what
should
be
improved.
Next
is
a
different
question
and
figuring
out
what
the
binary
size
is
is
also
another
totally
different
question,
so
figuring
out
what
the
binary
size
is
at
the
moment,
I'm
kicking
around
a
little
bit
looking
at
the
mid
compilation,
assembly
output,
and
that
gives
some
interesting
information,
but
again
very
hands-on,
trying
to
get
totally
automated
answers
out
of
this
out
of
the
gold
tool
chain.
G
It's
possible
that
I
just
haven't,
found
the
right
knobs.
Yet
the
answers
can
also
vary
a
lot
based
on
how
clever
the
compiler
gets
about
tree
shaking
stuff,
and
so
far
I've
actually
found
the
compiler
is
annoyingly
clever.
It
tree
shakes
too
well
on
the
simple
demos
that
I
make,
and
so
it
effectively
gives
me
no
information
about
the
size
that
a
real
user
is
likely
to
hit.
G
C
Hello
yep
mainly
last
week,
I
spent
getting
remedy
for
these
calibration
sessions
for
our
reviews,
but
also
got
a
bunch
of
work
done
on
cadb
the
new
block
store.
I
have
transactions
working
now,
there's
some
bugs
and
delete,
but
my
pens
work
perfectly
now
and
I
can
see
how
it's
performing.
C
This
is
really
like:
the
first
big
use
and
place
where
we're
really
performance
testing
these
new
trees
that
makola
figured
out
and
they're
really
nice
then
like
these
are
just.
This
is
like
a
really
nice
data
structure.
We're
gonna
be
able
to
do
some
really
cool
stuff.
With
this,
this
is
just
the
first
one,
but
anyway
this
this
database
is
actually
performing
pretty
quickly
initial
tree
creation.
You
can
do
like
around
three
hundred
thousand
rights,
a
second
and
dude,
creating
an
initial
tree.
C
I
expect
the
the
mutation
performance
to
come
down
from
there
probably
around,
like
a
hundred
entries,
a
second
for
bulk
updates,
but
that's
still
like
considerably
fast,
like
that's
faster
than
any
other
on
this
data
store
that
I
know
about
right
now,
so
yeah,
that's
exciting
stuff
should
get
that
in
better
shape
this
week
and
then
figure
out
where
to
go
from
there.
C
I'm
gonna
need
to
document
it
and
get
it
out
of
just
my
head,
probably
work
with
with
rod
on
how
to
write
a
good,
spec
and
docked
for
that,
and
then
also
sit
down
at
some
point
with
jeremy
and
go
over
what
the
plan
might
be
to
get
an
implementation
and
go
that
filecoin
could
use
and
then
yeah
mccola
is
on
this
grant
to
do
rather
b
tree
and
he
he
got
an
initial
implementation
up.
C
So
you
can
check
out
the
the
ravensbee
tree
that
he
wrote
as
well
looks
pretty
it's
in
typescript.
So
if
you're
interested,
if
you're
one
of
the
people
on
here
that
likes
typescript,
you
might
want
to
check
that
out
as
well
and
yeah.
That's
that's
what
I
got.
D
C
Yeah
yeah,
I
I
think
also
like
it-
doesn't
actually
use
wrapping
like
rabbits,
actually
not
a
great
algorithm
for
this.
C
Yeah,
no,
he
has
a
chunker
in
here.
Let
me
look
at
his
chunking
logic.
Here,
yeah
I
mean
he
just
has
some
some
math
that
he's
doing
on
on
it
there
with
some
bit
masking
and
whatnot
yeah
I
mean
yeah,
you
can
see
his
chunking
thing
and
that's
definitely
not
the
rabbit
algorithm
for
what
I
can
tell
so
yeah.
I
know
I
that
was
his
initial
name,
but
even
as
he
was
coming
up
with
that,
he
said,
that's
not
a
good
name.
I
think
so.
C
That,
like
has
a
plugable,
chunker
and
some
other
kind
of
plugable
attributes
that
we
can
talk
about
and
discuss
the
design
of,
but
we
should
be
able
to
get
like
a
kind
of
unified
implementation
where
you
can
just
implement
new
chunkers
and
new
sorters,
and
and
vary
some
of
the
schema
for
the
keys
and
values
a
little
bit
and
just
have
like
a
very
generic
data
structure
in
terms
of
the
implementation
for
reading
and
doing
range,
queries
and
stuff
like
that,
and
even
for
for
for
the
creation
of
mutations,
that'll
be
really
nice
and
then
we
can
basically
leverage
that
to
do
sparse,
arrays
and
you
know
bigger
maps
and
like
all
kinds
of
different
data
structures
that
we
can
build
like
on
top
of
this
basic
tree.
C
And
then
obviously,
each
of
those
data
structures
are
going
to
have
different
performance
profiles
that
we
need
to
tweak.
I
need
to
plug
in
different
settings
and
stuff
like
that,
but
it'll
be
it'll,
be
pretty
cool
all
right.
That's
me.
A
Thanks
chris,
do
you
have
anything
to
report?
Even
if
there
was
no
progress.
A
Really:
okay
thanks!
So
then
we
get
up
to
the
chin
items.
A
Dania
wants
to
talk
about,
go
multicode
versus
girl,
multi
formats.
F
Yeah,
so
this
one
should
be
an
easy
one,
so
I
just
want
to
export
the
multi-formats
table
as
a
list
of
constants,
which
I
guess
I
can
call
codes,
but
I'm
not
gonna
insist
on
that.
So
I
think
the
library
should
be
called
go
multi-formats.
F
G
G
I'm
scrambling
to
reload
that
document
right
now,
because
I
don't
remember
either,
but
I
thought
somebody
had
actually
tested
that
multi-base
is
specifically
not
a
multi-format
because
of
some
detailed
reason.
I
thought
I'm
not.
G
C
A
A
So
this
was
kind
of
the
discussion
we
had,
but
I
also
don't
really
recall
the
account
to
be
honest,
but
coming
back
to
danielle's,
question
hope
might
be
made,
might
make
more
sense,
and
so
currently's
problem
currently,
is
that
the
we
currently
have
something
in
javascript,
which
is
called
js
multicodec,
which
is
just
the
table
which
kind
of
like
you
are
currently
building
is
exactly
what
you
do
and
what
we
currently
there's
a
new
repository
for
the
all
new
stuff
which
combines
cid,
multihash
and
multibase
into
one
thing,
and
this
is
what
we
currently
call
js
smarty
formats.
A
C
What
is
a
multi-codec
without
iflb,
though,
because,
like
I
feel
like
we're,
we're
saying
that
multicodex
is
this
thing
that
multi-hashes
aren't,
because
we
know
what
the
data
model
is
and
what
it
means
and
how
we
assign
codex
to
these
things.
But
from
the
point
of
view
of
multi-formats,
it's
just
a
table
of
integers
to
identify
those
I
feel
like
those
are
all
multi-codecs
and
some
of
them
are
to
hash
functions
and
some
aren't
and
that's
the
main
difference.
G
G
Talk
about
these
terms,
the
fact
that
this
table
is
currently
called
multi-codec
and
contains
a
bunch
of
references
to
stuff
that
we
would
not
call
codex
is
deeply
confusing
to
us,
for
example,
multihash
also
being
in
this
table
is
confusing.
To
most
of
us,
cid
is
being
in
this
table
is
confusing
to
most
of
us.
I
could
go
on
with
that
list
for
some
time
if
I
just
scrolled
through
the
table
itself,
so
I'm
not.
C
G
And
that
had
tepid
support,
but
also
very
little
opposition.
It
just
didn't
have
strong
feelings
from
anyone
present.
So
that's
where
we
ended
up
parking
it.
Nobody
could
come
up
with
a
strong
resolution
of
what
we
want
it
to
be,
but
everybody
agreed
that
it
currently
being
called
multi-codec
is
deeply
confusing
and
should
be
changed.
C
That
seems
to
like
make
sense
to
me.
Like
I
don't
know,
I
tend
to
flatten
all
of
these
things
too.
These
are
just
variables,
in
particular
data
structures
and
that's
where
the
meaning
gets
applied.
So
we
don't
need
to
worry
about
the
meaning
in
each
of
those
data
structures.
What
we
need
to
worry
about
is
what
is
the
meaning
of
the
table
and
the
meaning
of
the
table
is
just
to
map
like
well-known
protocols
to
images
basically.
G
I
think
at
this
point
my
personal
theory
is,
we
should
do
a.
We
should
do
a
venn
diagram
of
this,
like
visually.
C
C
I
mean
we
could
call
it
multi-id,
we
could
call
it
multi-table
like
I
like
anything
really.
I
do
think
that
only
codec
does
get
a
little
confusing,
but
I'm
not
a,
but
I'm
not
ascribing
as
much
meaning
to
multicode,
as
I
think
other
people
are.
C
A
Okay,
I
should
probably
put
this
in
the
notes
at
this
quick
discussion,
but
like
what
is
now
the
answer
for
for
danielle.
Basically,
so
is
there.