►
From YouTube: 🖧 IPLD Bi-Weekly Sync 🙌🏽 2018-04-01
Description
A bi-weekly meeting to sync up on all IPLD related topics. It's open for everyone and recorded. https://github.com/ipld/team-mgmt
A
A
Yeah,
there's
not
that
much
agenda,
but
let's
start
with
the
two-week
update.
My
update
is
pretty
short,
it's
in
the
meeting
minutes
and
there's
plenty
of
links,
but
what
I
basically
did
is.
Finally,
the
new
jeaious
IP
AP
j,
SI,
p
LD
api
is
merged
and
released,
and
then
afterwards
we
had
a
lot
of
discussions
about
the
JavaScript
API.
That's
still
ongoing
and
yeah,
it's
it's.
Basically
the
generation
after
the
current
one
and
we'll
see
how
this
goes
and
just
follow
the
links
over
there
and
for
the
next
three
weeks.
A
I
will
probably
work
on
the
format's
IP
LD
format,
stuff
again
to
basically
do
the
implementation,
the
excellent
imitation
foreign
draft.
We
have
so
that
the
consumers
like
to
mix
FS
can
finally
use
the
sync
away.
The
API
annex
was
basically
asking
for
it
when
it
is
finally
done
and
hopefully
yeah
we
have
this
soon.
That's
all
I
have
next.
My
list
is
Michael,
hey.
B
So
I
have
a
couple
items
that
are
like
things
to
update
on
and
then
a
few
things
that
we'll
have
a
discussion
of
that.
So
all
I'll
push
some
of
the
discussion
off
until
later,
but
just
mention
it
real,
quick
one
is
that
the
big
thing
is
like
University
to
draft
has
been
updated
to
the
latest
spec.
It
doesn't
you'd
still
see
more,
only
and
kind
of
assuming
stibor
until
the
next
rep
of
the
IPO.
The
interfaces
finishes.
B
It's
going
to
be
a
little
bit
too
hard
to
update
it
to
just
be
really
agnostic,
but
right
now
it
does
work.
It
is
like
path,
agnostic
and
all
that
stuff,
and
it
has
almost
complete
code
coverage
now,
just
a
few
more
lines
to
really
do
so.
The
docs
are
up
for
the
summit
in
Berlin
I
sent
them
out
in
the
slack
room.
B
But
if
you
haven't
gotten
those,
let
me
know
and
I'll
make
sure
that
you
are
added
to
them
or
given
a
link
or
whatever
you
need,
but
they
there's
three
of
them
the
details,
sort
of
like
the
first
two
days
and
then
the
last
two
days
of
our
time.
In
Berlin
the
last
two
days,
we're
going
to
open
up
a
bit
more
and
sort
of
invite
more
people
in.
So
that's
why
there's
separate
documents?
B
Yeah
well,
yeah
I
think
like
they
are
really
useful.
Once
I
realized
they
existed.
The
issue
is
it
like
all
of
our
Traverse
errs
sort
of
assumed
that
if
CID
is
a
reference
to
something
that
you
pull
out
of
the
box
or
not,
that
like
the
CID,
would
just
have
the
data
in
it
as
part
of
the
multi-touch,
so
I
think
like
we,
we
may
need
to
be
considering
that.
D
D
D
This
function
is
now
implemented
completely
and
works
and
is
agnostic
to
any
links
in
the
middle
of
that
path.
So
that's
really
cool
that
allows
us
to
do
some
stuff
that
I
think
has
kind
of
never
been
supported
before
it
doesn't.
Let
you
mutate
things
the
middle
of
the
path
that
would
require
a
little
more
blue
coat.
That
ask
me
happened
right,
but
it
lets
you,
like.
You,
show
up
into
anything,
do
something
which
is
AB,
you
only
sort
of
operation
and
that's
really
cool
them.
D
That
has
test
cases
now
and
that
has
sort
of
proven
out
a
whole
bunch
about
their
code
and
I.
Do
D,
prime,
which
is
basically
not
been
tested
before
so
more
finely
grained
tests
for
a
bunch
of
this
stuff
would
be
very
welcome,
but
some
very
high
level
integration
tests
are
now
like
working.
So
that's.
C
D
A
word
I
made
up.
It
means
that
we
are
so
given
some
node
and
given
some
path
or
a
path
like
a
series
of
path
segments,
each
of
them
being
one
specific
jump
that
you
might
make
so
I
could
got
a
map
and
you've
got
a
key
index
immediately.
That's
more
passing
list.
We've
got
one
integer
index
in
increments
path,
segments
and
so
on.
D
D
Do
the
right
thing,
and
so
it's
really
nice
to
have
the
the
focus
implementation
there.
So
it
shows
what
the
depth
of
complexity
is,
that
we
will
get
to
and
jump
into
and
specific
could
have
in
the
tree
and
now
I'm
trying
to
make
that
stuff
work
for
selectors
in
general
for
like
a
whole
and
subsection
of
the
trees
is
really
interesting.
I've
started
trying
to
work
on
that
this
week
and
it's
you
maybe
constrain
myself
saying
it's
really
interesting.
D
Yeah,
it's
really
interesting.
So,
for
example,
I've
started
to
look
at
the
bash
code
that
does
the
nearest
equivalent
to
some
of
the
most
general
things
that
we've
wanted
to
ask
from
this
social
system
and
I'm
not
sure.
If,
if
anyone
else,
the
room
is
familiar,
so
in
so
mash
it
can
be
like
doc,
slash
star
and
it'll
match,
one
thing
where
the
star
is
and
then
a
feature
which
often
converts
people
to
Z
SH,
for
example,
but
also
exists
in
bash,
is
called
Club
star.
So
it's?
D
C
Guess
it's
a
really
good
intro
to
data
structures
in
IPL
Diaz,
and
it
seems
to
me
that
they
jump
to
different
kinds
of
collections.
Isn't
that
great?
Once
we
have
basic
collections
in
place,
so
I've
done
any
I've
done
a
hampt
implementation
in
JavaScript
it's
of
a
champ
variety
which
there's
a
couple
floating
around
of
the
variously,
implement
that
it's
it's
a
little
bit
like
the
one.
C
That's
that's
in
go
at
the
moment,
let's
go
hand,
obld
I
think
it's
called,
but
that
I
mean
that
doesn't
stick
to
any
particular
spec
and
it's
a
little
bit
loose
in
some
areas.
So
it's
it's
sort
of
similar
to
that.
But
not
quite
it's!
It's
a
bit
more
close
to
the
one
in
in
Ian's,
pier
gusts
thing
anyway.
C
It's
so
I've
modelled
it.
So
it
feels
like
a
JavaScript
map,
but
it's
asynchronous
and
immutable.
So
every
every
mutation
of
our
operation
creates
a
new
node
that
you
then
need
to
do
something
with
so
serialize
or
keep
on
mutating,
and
it's
working
really
well
I,
I'm,
currently
bogged
down
in
getting
tests
covering
weird
edge
cases
in
the
compaction.
So
that's
you
know
making
sure
that
the
different
forms
of
trees
when
you
delete
nodes
that
they
compact
up
properly,
there's
a
bunch
of
different
ways
that
they
can
be
formed.
C
There
are
special
cases
so
and
I'm
trying
to
get
test
cases
that
form
the
trees
in
those
ways
and
then
compact
them
in
in
the
right
way,
just
to
show
that
it
works
and
and
in
doing
that,
I
found
some
problems
in
the
in
my
algorithm.
So
it's
going
well.
It
does
raise
a
bunch
of
interesting
questions,
though,
which
I
I'm
hoping
to
I'm
hoping
to
get
this
up
in
the
next
couple
of
days,
so
that
we
can
start
having
these
discussions
because
I
think
they're
really
interesting.
C
So
things
like,
what's
the
final
serialized
form
of
this
thing
of
these
data
structures
and
I
know
need
some
help
from
you
guys
who
have
been
serializing
stuffing
to
see
ball
more
than
I.
Have
you
know,
I
I
just
reach
for
just
a
naive
sort
of
serialize
realization,
but
it
would
be
they
probably
take
up
more
space
than
it
needs
to
what's
the
optimal
branching
factor,
the
optimal
bucket
size,
when
is
in
line
versus
linked
entry
storage
best?
C
It
is
there's
lots
of
documentation
it,
even
though
it's
the
the
structure
is
complex.
It's
heavily
documented.
The
tests
test
should
be,
should
explain
a
lot
better,
so
hope,
I'm,
hoping
that
those
kinds
of
discussions
are
practical
when
we've
got
something
to
look
at.
That
is
not
too
difficult
to
grok.
So
that's,
hopefully,
in
the
next
couple
days,.
A
No,
all
right,
so
yeah,
so
only
I've
put
also
Michael
stuff
on
the
agenda
list
under
the
agenda
in
this
meeting
and
kind
of
like
like
what
I
want
to
talk
about.
Is
this
and
nested
ILD
formats
on
distant
blocks
or
inline
block
sort
or
either
we
call
them,
but
this
basically
overlaps
what
you
likely
wants
to
discuss
so
I
guess
I
just
hand
over
to
Michael
and
and
yeah
yeah.
B
B
Okay,
so,
like
I
was
reading
the
thread,
I
think
it
was
like
in
2015.
One
was
like
you
know
what
sometimes
the
data
that
you're
hashing
is
smaller
than
a
hash.
So
why
don't?
We
just
like
add
a
multi
codec
for
instead
of
a
hash,
here's
just
the
data,
here's
the
bytes
and
use
that
as
the
identifier,
if
it's
going
to
end
up
being
shorter
than
a
multi
head
or
shorter
than
the
actual
hash.
Anyway.
B
This
is
binary
data
in
front
of
it
and
then
because
C
IDs
are
just
like
extra
metadata
on
top
like
in
front
of
a
multi
hash,
you
could
do
what
is
effectively
an
inline
block
by
just
saying:
oh
here's,
the
CID
with
an
identity,
multi
hash
and
all
in
the
bite
area
and
there's
no
limit
on
the
size.
So
the
thing
that
that
like
because
almost
an
asking
for
is
effectively
accomplished
with
this
because,
like
you,
can
just
keep
embedding
them,
you
can
even
nest
them.
B
A
B
Mean
it's
effectively
the
exact
same
thing
as
we
were
talking
about
right,
which
is
taking
the
codec
and
mashing
it
up
against
the
binary
block,
and
then
just
embedding
the
binary
data
like
it's
not
really
that
much
different
I.
Think
like
the
only
thing
that
really
changes
is
that
so
we
there's
this
thread
that
I
have
it
in
in
Dec
JSON
about
like.
A
B
No,
but
but
then,
then
the
block
data
doesn't
actually
get
encrypted
with
the
same
color
soo
yeah
yeah
like
like.
That's
the
reason
that
you
need
to
inline
the
data
yeah
like
you're,
you
yeah
you'd,
effectively
like
it
would
be
fine
if
you
were
only
worried
about
the
security
of
like
the
graph
indexing,
but
if
you're
worried
about
like
the
security
of
the
entire
block
store
and
not
storing
anything
in
plain
text,
if
it's
actually
encrypted,
then
you
would
end
up
and
storing
a
bunch
of
plaintext
like
blocks
that
people
thought
were
getting
interrupted.
A
A
B
C
B
C
B
B
B
I
mean,
to
my
mind,
like,
like
the
ideal
case,
was
actually
something
very
different
and
where
we
ended
up
going
in
this
direction
is
just
the
fact
that,
like
no,
we
want
to
be
able
to
have
data
from
other
formats
get
encrypted,
along
with
other
block
data.
Like
that's,
that's
the
main
point
so
like
if
I
want
to
link
into
a
get
block
and
then
I
want
to
go
and
encrypt
the
entire
structure.
I
effectively
get
a
bunch
of
blocks
that
are
all
encrypted
right
and
I.
B
Don't
lose
any
of
that
like
linking
nature
of
IPL
B
into
the
get
walk
and
like
at
first
I
kind
of
hated
this
and
now
it
seems
like
kind
of
the
most
elegant
thing
in
a
weird
way
like
well
no,
but
but
to
be
clear,
like
I,
think
that
I
think
that
this
should
just
be
in
at
some
point,
it's
just
going
to
be
encoded
in
some
kind
of
minor
ever-so.
B
It's
just
that
that
gets
decrypted
and
then
like
interpreted
as
you
know,
whatever
you
reference
in
the
in
the
encryption
data,
does
that
make
sense
like
I?
Don't
think
that
we
should
use
these
in
lancia,
like
if
I
said,
if
it'll
NC
ID
was
dag,
C
bore
and
then
I
gave
you
the
whole
binary,
but
it
was
encrypted.
You
would
have
no
way
to
decrypt
it
right.
It's
like
like
that,
doesn't
really
work
so
for
the
purpose
of
encryption,
we're
still
going
to
have
to
have
a
field
in
there.
B
E
What
is
the
maybe
I'm
I'm
also
missing
some
of
this,
like?
What's
the
what's
the
use
case,
it's
like
okay,
I
have
like
I,
have
a
JPEG
and
I,
don't
wanna
I,
don't
want
to
just
send
you
the
I,
don't
want
to
encrypt
the
JPEG
in
and
put
the
encrypted
hash
in
the
in
the
CID
I
want
to
actually
just
in
line
the
whole
JPEG
and
send
it
to
you.
Well.
B
So
a
peg
is
relatively
easy
because
that's
just
still
raw
binary
data
I
think
that
the
problem
is
that,
like
say,
say:
I
have
a
data
structure
that
I
want
to
encrypt
like
the
whole
thing
right
then,
and
some
of
the
links
in
that
are
to
like
etherium
blocks
and
get
blocks
I
need
to
encrypt
those.
That's
part
of
the
data
structure,
so,
what's
gonna
have
to
end
up
happening,
is
like
I'm
gonna
have
to
inline
that
data
somewhere
in
some
other
block.
B
It's
actually
fully
gets
encrypted
and
can
be
interpreted
as
part
of
the
encryption
program
I'm.
The
main
issue
is
that,
like
all
this
metadata
that
we're
talking
about
adding
has
to
be
added
a
layer
above
the
thing
that
you're
encrypting,
and
so,
if
it's
not
in
the
IPL
deep
data
model
like
it's
in
these
other
content
addressed
formats,
it
effectively
has
to
be
inlinable
so
that
we
can
get
it
into
something
in
the
data
model
that
we
can
then
interpret.
B
E
Mean
as
opposed
to
like
this
new
structure,
you're
importing
right,
isn't
that
I,
maybe
I,
don't
understand
what
multi
codecs
are
really
supposed
to
be
for,
but
I
guess
I
thought
that
you
know
you
have
like
whatever
like
there's
like
a
multi
codec
for
like
this
is
what
I
get
commit,
looks
like
and
etc.
So,
if
you
we're
really
doing
had
one
of
these
structures
that
you
wanted
to
use
when
you
just
call
one
of
those
a
multi
codec
and
that's
how
you
would
specify
what
the
internal
structure
look
like
so.
B
You
have
data,
that's
already
in
a
multi
codec
like
it's.
A
git
commit
right
and
I
need
to,
like
I
have
some
about
that.
That
I
want
to
encrypt
and
I
also
want
to
encrypt
the
block,
so
that
I
can
send
it
to
somebody.
Even
if
it's
multiple
blocks
I
consented.
Somebody-
and
nobody
knows
what's
in
right,
so
I
need
two
things.
Right.
I
need
a
bunch
of
information
about
the
encryption
that
I
like
that.
B
I
send
and
the
data
around
it
that'll
need
to
get
encrypted,
and
then
I
need
to
have
a
reference
to
this
block
with
with
that
multi-coated
with
the
get
multi
codec
in
front
of
it,
so
that
we
know
how
to
interpret
the
block
data.
But
if
I
make
that
a
separate
block,
then
it
won't
end
up
getting
encrypted
right
because
then
the
hash
would
match.
B
C
We're
talking
about
eight
right,
so
we're
talking
about
packaging
these
within
just
just
a
small
shell
that
has
the
additional
metadata.
So
I
was
picturing
as
these
things
go
inside
anything,
so
you
could
have
you
know
a
block
with
a
lot
of
stuff
in
it.
Then
you
just
have
this
hanging
on
the
side,
but
no
it's
just
like
it's
just
a
boxing
mechanism.
Yes,.
B
Like
infinite
nesting,
but
like
there's,
there's
a
bunch
of
other
reasons
why
you
don't
want
to
have
gigantic
blocks?
So
that's
probably
okay
like
if
somebody
ends
up
creating
gigantic
blocks
like
they
won't
work
in
a
bunch
of
places.
So
it's
alright,
there's,
there's
enough
incentive
already
to
reduce
block
size,
I'm.