►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2020-05-04
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
A
Please
put
your
name
on
it:
a
nice
list
yeah.
So
I
start
with
myself.
So
in
the
past
week,
I've
done
work
on
the
last
icon,
D
on
a
block.
Api
I
thought
it
was
ready
and
then
I
figured
out
that
obviously
also
IP
LD
needs
to
be
generic
over
codex
so
that
it
can
pass
in
your
own
colleague
table.
Currently
IP
LD
just
uses
the
correct
table
that
Marty,
hash
and
CID
provides,
and
that's
kind
of
like
a
bigger
change
and
probably
needs
a
bit
more
of
discussions
with
other
contributors.
A
So
I
will
do
this
change
first
and
then
come
back
to
the
book.
Api
then,
on
the
take
Chason
spec
I
opened
up
the
hour
about
making
things
clearer
and
tightening
it
down
and
there's
clearly
discussion
and
I.
Hopefully,
hopefully
we
can
resolve
this
and
just
keep
that
they
chase
on
simple,
because
it
doesn't
seem
to
be
agreement
on
the
base
encoding
of
the
C
IDs
but
yeah.
A
B
Yeah
yep
so
got
most
of
the
multi-format
stuff
done
all
the
specs
are
implemented
now
the
CNE
stuff
is
there
with
all
the
braking
exchanges
and
full
test
coverage.
Now
we're
talking
about
this
binary
stuff,
trying
to
figure
out
if
we
can
drop
the
buffer
API
or
not.
It's
we're
good,
like
we
may
know
so.
Yeah
I'll
stay
on
top
of
that
next
steps.
There
are
two
start
to
port
over
all
the
codecs
and
then
pour
over
the
new
block
interface.
B
B
Also
I
made
more
progress
on
on
dengue,
D,
so
there's
there's
an
indexing
engine
now
this
is
a
really
interesting
data
structure
to
build.
That's
been
fun
had
to
go
in
and
add
enum
support
to
the
schema
validation
library
that
I
wrote
so
that
pretty
much
I
think
a
complete
implementation
of
the
schema
language,
I'm,
pretty
sure
I'd
be
missing
a
few
corners
here,
but
I
think
I
got
all
of
them
now.
B
Oh
I
also
trained
him
really
nasty
bug
in
the
block
API
working
on
the
stuff,
where
you
were
passing
in
just
simple
pipes
that
weren't
embedded
inside
of
strings
in
the
way
that
we've
actually
messing
them
up
quite
a
bit.
So
it's
really
bad
and
kind
of
got
a
relief
that
for
that,
so
that's
fixed
now
and
that's
about
it
for
IPL.
This
definitely.
C
A
bunch
of
stuff
that
was
started
ages
ago
and
just
kind
of
languishing.
The
type
theory
glossary
which
had
a
ton
of
comments
from
people
in
and
out
of
this
group
is
now
landed
thanks.
Everyone
for
comments
on
that.
So
it's
also
terrifying.
To
try
to
do
any
coherent
talk
about
a
summary
of
type
theory
in
which
we
don't
give
too
much
credence
to
any
particular
terms,
but
still
get
super
concrete
and
constructed.
Those
are
really
hard
balance
to
strike.
C
So
it's
probably
still
not
perfect
by
the
way,
not
even
know
that
it
is
so
if
anyone
has
subsequent
PR
alone
that
great
the
library,
design
recommendations,
doc
has
also
merged
and
I
started.
Doing
a
ton
of
example,
stuff:
okay,
not
at
all
I
started
doing
example
stuff
in
the
go:
I
filled
the
primary
pump,
so
those
are
test
files
that
are
executable
and
also
those
show
up
as
examples
of
the
documentation
online,
probably
going
to
need
even
more
of
those
but
there's
a
start.
C
That
the
Java
Script
is
reviewing
at
the
same
time
is
this
chip
I've
been
trying
to
solve
for
how
to
have
a
reasonable
interface
for
links
and,
at
the
same
time
not
have
a
really
concrete
dependencies
between
the
linking
codex
and
such
things
as
this,
so
that
the
dependency
tree
transitively
doesn't
get
out
of
hand
and
the
solution
that
I
have
for
this
one
go.
Currently
it
works,
it
doesn't
have
a
dependency
tree
that
gets
out
of
hand,
but
it's
also,
you
know
very
pleasant
or
terse
to
use
so
like
nobody's
really
happy
with
it.
C
Myself
included.
I've
generated
a
lot
more
notes
on
that.
If
anybody
wants
to
check
them
out,
maybe
they'll
be
cosplaying
with
local
I.
Don't
know
more
effort
still
need
it
there
in
the
future.
I
guess.
The
only
piece
of
good
news
for
a
week
is
a
bunch
of
other
transit
dependencies
of
go
IPL
d-prime.
The
ball
now
gone
on
the
latest
generation,
where
I've
got
the
note
assembler
stuff.
So
that's
exciting.
That's
about
it!
For
me,.
D
Doc
has
focus
said
we
think
we've
arrived
at
that
I
think
they're
ready
to
merge
if
I
could
just
make
that
happen
and
make
that
team
happy
I.
Suppose
it's
not
it's
not
entirely
satisfactory,
but
I
think
I
think
that's
reflective
of
this
problem,
which
is
we're
tempted
to
make
this
satisfactory
to
our
model.
But
so
many
of
these
different
ecosystems
that
are
using
that
will
want
to
use
these
things
are
gonna
have
their
own
models
that
don't
necessarily
overlap
100%
with
ours
and
so
I.
D
D
It
was
skipping
over
some
things
and
so,
and
it
also
wasn't
doing
the
full
I
hadn't
got
it
doing
the
full
round-trip
that
I
needed
it
to
do
so.
Can
ID
code
represent
the
native
structures
and
then
Rhian
code
again,
and
so
I
did
that
last
week.
Finally,
the
whole
lot
so
and
then
I
went
through
the
blockchain
I
found
some
edge
cases,
so
I
can
I
can
now
tell
you
all
of
the
edge
case
blocks
in
their
Bitcoin
blockchain
that
have
novelty
in
them,
so
pulley
try
those
out
and
put
them
into
my
test.
D
D
Sort
of
the
block
stuff
is
also
bundled
up
in
there
as
well,
so
so,
basically
trying
to
move
away
from
the
old
API
where
you've
got
you
know,
util
and
then
serialize
and
resolve,
and
this
strange
structure
and
doing
something
a
little
bit
more
native
to
the
new
block
API,
so
encode,
decode
and
whatever
the
third
one
is,
and
so
because
I
need
to
do
that
for
at
least
three
different
types.
Now
so
I've
got
three
different
codecs
for
Bitcoin,
and
so
that's
the
plan
there
I
I,
think
I've.
D
Currently
integrating
my
work
into
the
old
Bitcoin,
JavaScript
library,
I
haven't
put
that
on
github,
yet
but
I
think
I'm
just
gonna
involve
that
to
the
new
stuff.
Put
the
other
two
in
there
other
two
colleagues
in
there
and
make
sure
I've
got
a
test
thing
going
on
for
that
and
in
yeah
I
think
that
that
work
should
go
fairly
quickly.
Now
then,
I've
got
those
sort
of
hard
tedious
bit.
D
A
Thanks
does
anybody
also
have
any
updates?
I
have
one
thing:
I
forgot
to
say
that
for
the
next
week
is
that
also,
basically
for
also
for
people
watching
that
and
crudely,
currently
there's
a
huge
interest
in
graphs,
Inc
and
also
kind
of
related
selectors,
but
it's
Remo,
stressing
and
I
couldn't
try
to
get
all
people
together
that
are
interested
in
implementing
so
because
they
graph
thing
is
also
using
five
coin
and
inactive
s.
So
there's
interest
from
the
rust
side
of
things
on
both
sides.
A
Also,
there
is
interest
on
that
shallow
script,
side
from
Chris
and
yes,
so
just
I
try
to
Lee
to
collect
all
the
people
getting
them
together
and
then
yeah
move
forward.
So
they're
not
too
many
double
efforts,
and
also
things
like,
for
example,
I've
talked
with
people
about
selectors
that
currently
there's
the
reference
implementation
is
ago,
and
there
is
also
testing
go,
but
it's
really
like
they're
written
go
and
perhaps
create
something
that
takes
test
features.
They
can
be
used
across
languages
and
so
on
and
stuff
like
this.
A
So
this
repeater
yeah
what
I
want
to
get
people
together
and
then
discuss
and
so
on.
So
expect
like
yeah
just
tell
me
and
then
I
will
make
sure
you
are
involved
and
then
yeah
I
won't
yeah
post
on
all
the
issues
where
things
are
happening
and
so
on.
So
that's
kind
of
my
plan,
I'm
not
sure
how
soon
this
would
happen,
but
it's
probably
this
starting
this
week
and
then
going
on
to
next
week,
but
yeah.
It's
just
yeah
too
many
people
are
too
busy.
So
we'll
see
how
this
goes
yeah!
A
A
If
there
are
no
questions,
I
might
quickly
talk
about
the
deck
chase
on
PR,
because
it
looks
like
it's
the
beginning
of
a
long
discussion.
Again.
I
am
currently
so
deck.
Chase
is
basically
a
format
which
is
yeah
mostly
for
debugging
purpose
and
currently
I
want
to
tighten
up
the
spec
a
bit
and
I
thought.
It
would
make
sense
that
we
just
restrict
the
CID
is
to
base64-encoded
M
C
IDs,
the
reason
being
that
it's
like
base64
is
just
like
available
everywhere.
A
Even
in
the
browser
in
the
soup
easy
and
the
problem
there
is
you
couldn't
encode,
for
example,
CID
version
zero
McD's
with
it,
but
honestly
I,
don't
see
a
problem
with
it,
because
you
can
just
encode
your
C
IDs
as
CD
version
1
and
then
transform
it
to
a
CD
versions.
Your
if
you
need
it
for
your
application.
A
C
C
B
C
A
C
B
E
Well,
but
here's
the
thing,
though
the
decoded
so
to
speak,
see
a
DB.
0
is
literally
a
multi
hash.
So
with
a
lot
of
conversations
about,
you
know
about
storage
changes
and
this
and
that
we're
we're
going
to
use
multi
hash.
Only
this
probably
not
directly
but
indirectly,
somehow
will
clash
with
something.
A
B
E
Absolutely
what
I
meant
is
that,
if,
in
the
store,
all
we
have
is
a
multi
cache
from
you
know
kind
of
one
code
path
and
from
another
code
path,
you
all
of
a
sudden
have
this
thing
that
used
to
be
always
AK,
but
now
is
this
by
narrating
the
disease
also
multi
cache.
You
might
end
up
in
a
weird
situation
and
I'm
not
saying
I
can
see
right
now
where
the
clashes,
but
it
just
gives
me
a
bad
feeling.
B
I,
don't
know
that
the
way
that
we
support
v-0
is
really
happy
but
kind
of
everywhere.
Yeah
I
know
I,
don't
know
what
a
good
solution
here
is.
Yeah.
A
But
I
but
I,
just
like
as
Eric
mentioned,
I
think
I
mean
DB.
There
is
some
JSON
output
from
my
PFS
and
I
think
it's
certainly
using
like
the
c
dv0,
of
course,
for
the
for
the
I'm
take
PP
api.
So
I
guess
that
that's
a
good
point
that
it
would
make
sense
to
support
those
and
then
we
need
to
support
yeah.
Basically,
all
types
of
series.
C
A
I
mean
like
it's:
it's
it's
also
like
it's.
It's
totally
fine
to
do
it.
This
way,
I
just
wanted.
We,
as
always
like
making
the
spec,
is
like
small
as
possible.
It's
not
having
like
all
possible
things,
but
if
that's
certainly
used
in
the
wild
which
I
wasn't
aware
of,
then
it's
gonna
make
sense
to
just
say:
well,
it
is
slash
and
then
a
pacing
call.
It
CID,
whichever
based
one
yeah.
C
B
A
A
D
E
B
A
B
D
D
You
don't
know
if
this
thing
was
a
visa
at
one
point
and
I
I
think
that
kind
of
information
that
that's
the
kind
of
information
I
think
is
more
likely
to
be
critical
in
some
path.
That
is
much
more
distant
from
where
we
are
like
somebody
write
down
the
down
the
the
software
stack.
That
is
relying
on
the
fact
of
V
zeros
and
then,
where
he
is
I
know,
everything
should
be
a
v1
life
and
I.
Think
that's
gonna
break
too
much
stuff
to.
A
A
B
C
B
C
B
B
No,
no,
that
the
new
CID
library
doesn't
do
that
either.
That's
a
10.
That
was
a
terrible
decision
like
yeah.
No,
that's
the
right
thing
to
do,
because
we
don't
want.
Is
you
you
want
like
deterministic,
behavior
Adam,
that's
extreme
API,
you
don't
want
it
to
like
yeah,
no
totally
I
I'm
in
agreement.
There
I
think
that,
like
my
my
sysm
about
about
the
spec
here
is
like
one
if
it's
multi
be
encoded,
decoders
you're,
just
gonna
pass
that
into
a
multi,
basically
coder
and
not
actually
check
if
it
was
improperly
encoded.
B
So
in
a
similar
situation
to
what
we
have
with
deterministic
key
sorting,
we
will
end
up
supporting
in
deterministic
behavior
here
on
the
decoder
we
just
need
to
like
specify
and
try
to
ensure
that
all
of
the
end
coders
do
the
same
thing
and
do
it
deterministic.
So
what
we're
really
saying?
It's
like
the
end.
Coder
should
always
use
basics
before
multi
base
for
v1
and
then
for
zero.
B
Do
the
base
to
do
B
to
see
the
last
thing
that
I'm
hesitant,
though,
is
that
we
have
gone
through
a
lot
of
effort
to
make
base
32
the
default
encoding
everywhere
so
like
the
default
for
2
string,
will
return,
base
32
or
base
the
abt
see
if
it
is
B
zero
and
that's
been
like
a
nice
really
easy
operation
that
you
can
do
without
checking
anything
well.
You're
now,
gonna
have
to
check
that
and
Dubey
64
explicitly
and
I
know
that
we're
gonna
save
bytes
in
the
deck
JSON
format.
It's
just
like.
A
To
me
reason
for
using
base.
64
is
basically
that
and
almost
everyday
English
has
space
64
support,
building,
unlike
standard
library
or
something
so
it's
like
it's
simply
easy
to
consume.
They
say
so,
no
pretty
use
it.
Even
if
you
don't
have
the
full
thing
hold
it
up
and
pace
32
you
don't
so
that's
my
reason
to
do
it.
B
E
B
E
A
B
B
A
E
But
I
mean
the
the
point
that
Michael
made
earlier
is
essentially
no
question,
because
if
somebody
needs
to
support,
say
dv0
in
any
shape
or
form,
they
need
to
have
big
na
right.
I.
B
A
You
would
need
like,
in
the
curtain
a
cooker
in
big
JSON
specification.
You
would
need
big
nominee
way
because
it's
we
represent
integers
as
big
numbers
in
JSON.
So
just
you
know
as
an
information,
so
we
currently
so
you
mean
besides
are
basically
you
would
need
big
numbers
support
in
order
to
pass
deck
chase
on
properly.
A
A
Them
in
using
so
the
current
specs,
so
it
can
spec
says
that
and
do
you
know
that
Jason
Jason
does
make
a
decision
on
how
big
the
numbers
aren't.
So
we
say
put
in
any
number
you
want
into
your
chase
on
the
air
for
also
in
Dec
chase
on,
and
you
need
to
make
sure
that
you
represent
the
number
in
your
language
whatever
it
is.
So
basically
so.
Currently,
if
you
use
a
JSON
browser,
you
can
use,
you
can't
pass
they
chase
or
natively,
basically,
because
there
might
be
a
big
big,
integer
number
it.
A
D
Path
where
it's
like,
okay,
do
you
want
big
numbers
support?
Well,
then,
you're
gonna
have
to
opt
in
to
stuff,
but
but
you
can
you
can
parse
this
stuff
natively,
it's
just
that
you
may
not
get
big
numbers
out
of
it.
So
it's
like
you
have
talked
in
as
a
consumer
of
the
of
these
libraries.
Yes,
one
that
hassle,
then
its
life,
like
the
CID
version,
zero
thing.
If
we
can
make
that
pluggable,
do
you
want
CID
version
zero
to
be
supported
or
throw
exceptions?
Well,
it's
up
to
you.
E
B
B
So
that
has
implications
on
ordering
in
maps,
and
it
also
has
implications
in
JavaScript
for
number
representation,
because
if
you
round
the
numbers,
then
you're
not
going
to
get
the
same
hash
when
you
think
of
that's
the
problem
so
like,
if
somebody
you
know,
if
you
we're
not
saying
how
you
have
to
parse
that
in
order
to
in
order
to
preserve
the
number,
we're
just
saying
that,
like
your
encoder
and
decoder,
need
to,
you
know,
reliably
produce
the
same
thing.
Even
when
you
have.
B
A
Okay,
I'm,
coming
back
to
the
base
encoding,
so
I
mean
I,
don't
care
if
it's
base64
our
base,
32
dagger
man
famous
both
I
just
saw
that
basics.
It
was
more
so
Oh,
basically,
okay.
The
point
is
I
also
want
to
do
base
64
us
because
we
encode
binary
this
base
64.
So
you
need
a
basics
before
encoded
for
that
one
anyway.
So
I
thought
well
make
sense
to
also
base
encoder
cities
because
well
we
have
that
anyway,.
D
E
D
B
This
nice,
so
what
what
the
trade-off
that
we'd
be
making
is
that
we'd
be
eating
bytes
in
the
block
format
for
saving
our
e-base
encodes
when
we
do
stuff
with
them
later,
because
that
that
basic
encoding
does
get
cached
when
it
gets
when
it
gets
parsed,
so
we
never
actually
have
to
generally
did
again.
So
there
is
like
a
slight
efficiency
gain
on
the
compute
side,
but
we're
we're
literally
adding
why
it's
the.
A
E
A
Like
to
be
the
point
about,
digestion
is
it's
a
format
that
represents
the
data
model
and
you
can
use
it
mostly
I
guess
for
debugging
purposes
or
for
exchanging
on
platforms
where
you
don't
really
have
like
a
Seabury
encoder
or
something
so,
but
he
limited
platforms
and
therefore
I
think
it
makes
sense,
Missy
stripped
down
the
dependencies
on
like
external
things
you
need.
So
if
you
need
only
a
base64
encoded
for
decoding
binary,
you
have
that
already.
You
would
need
to
have
another
base
encoder
for
your
CDs.
A
D
It
could
I
just
I
can
just
imagine
it
getting
annoying
where
you've
got
Jade
egg
Jason
Darla
I
mean
you're,
looking
debugging
or
you're
looking
through
stuff,
and
you
get
coming
into
these
CI
days
and
you
have
to
pull
them
out
and
decode
basics
for
re
and
code
base.
That
is
you
just
to
see
what
CID
that
is
like
you
have
to
it's
like.
It
becomes
like
dealing
with
seaboard
where
you
have
to
pass.
A
B
A
D
A
So,
okay,
so
we
think
okay,
then
I
will
make
a
PR
on
the
spec
saying
that
CID
version
zero
is
base
58,
encoded,
CID
version.
One
is
space,
32,
encoded,
multi,
basically
yeah
and
that's
a
great,
and
then
you
have
a
canonical
representation
of
your
day
chase
on
because
round
trips,
yeah,
okay,
cool
thing,
so
I
guess
this
saved
about
like
I.
Don't
like
two
hours
of
everyone
discussing
it
on
github,
I!
Guess.
D
All
right
anything
like
sorry
just
to
continue
this
thought.
Michael
I
think
that
so
just
looking
through
the
basic
coding
stuff
in
JavaScript,
you
can
see
that
there
is
a
fast.
We
have
a
fast
path
for
base64
a
base
32
because
that's
fairly
easy,
but
for
base
58
and
the
other
novel
bases.
We
have
to
go
and
use
this
base,
X
library,
which
is
not
huge,
but
it's
another
dependency,
and
just
wonder
whether
it
would
be
worth
us
implementing
our
own
minimal
base.
58
biddies,
BTC
encoder.
D
B
D
B
I
mean
so
open
this
way
we
can
do
ship,
the
molding
format
stuff,
as
is
there's
already
a
base,
58
implementation
in
there.
That
requires
that
depth.
It's
just.
Obviously,
it's
not
loaded
in
by
default
or
anything.
There
is
a
basics
file
that
is
like
the
multi-format
slash
basics.
This
is
just
like
a
reasonable
set
of
defaults
that
don't
have
dependencies
and
it's
not
in
there.
If
we
replaced
it
with
one
that
didn't
have
any
external
dependencies,
then
I
would
just
add
that
to
the
basic
set
so
that
we
had
base
58
most
people
would.
D
Yeah,
the
basics
is
everywhere
as
well
cos
fun
again,
which
is
not
bad.
It's
not
it's
not
huge
dependency,
but
it's
it's.
It's
written
to
be
generic,
and
maybe
we
don't
need
generic
for
this
case,
but
and
if
you
opt
into
special
cases-
and
maybe
you
get
genetic
I'm-
probably
not
worth
dwelling
on
too
much
here,.