►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2020-10-13
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
I
start
with
myself
and
so
yeah,
so
I
spent
a
bit
of
time
not
too
much
on
the
wasm
stuff
and
just
to
explain
it
because
I
said
it
almost
every
week
but
didn't
explain
what
this
is
about,
and
so
the
idea
is
that
there
are
read-only
codecs
compiled
to
wasm,
and
the
idea
is
that
in
order
to
be
able
to
traverse
id
structures,
you
of
course
need
to
know
the
codec.
A
So
you
can,
for
example,
even
if
you
just
want
to
sync
blocks,
you
want
to
go
through
all
the
stuff
and
go
through
the
links
and
then
go
to
the
next
block
and
so
on.
But
in
order
to
do
this,
you
need
to
understand
the
coding,
and
hopefully
there
will
be
thousands
of
different
codecs
like
plenty
codecs,
but
you
have
to
understand
them.
A
So
it's
so
it's
kind
of
like
it
could
be
seen
as
like
a
stepping
stone.
If
you
want
to
have
your
traversal
working,
but
then
you
want
to
later
on,
implement
it
natively,
but
there's
a
stepping
stone.
A
You
just
use
the
awesome
stuff
which
is
kind
of
like
compound
with
the
hope
that
wasn't
is
really
hopefully
some
at
one
point
everywhere
and
you
can
just
use
it
in
your
programming
language,
and
this
is
combined
with
looking
into
stuff
and
it's
the
one
of
the
most
most
promising
things
in
the
wasm
world,
where
you
want
to
shuffle
around
types
from
one
from
the
host
language
into
the
most
runtime
is
interface
types
and
they
change
the
spec
all
the
time
and
don't
have
an
implementation.
A
So
the
header
implementation
who's
changing
the
spec.
What
was
the
spec.
A
That's
a
wasm
thing,
so
it's
a
it's
an
awesome
thing
on
how
to
generally
spoken
to
interact
with
boundaries
between
the
host
language
and
the
wasm
runtime
itself.
So
you
can
kind
of
like
expose
strings
on
a
higher
level
and
stuff
like
this,
and
it's
like
it
was
super
complicated.
It
got
just
recently,
so
there's
a
power
pin
to
make
it
simpler
and
also
based
on
other
other
awesome
proposals.
So
it's
really
like
it's
really
really
hard
on
the
road.
A
So
it's
like
it's
based
on
three
other
proposals
that
haven't
an
implementation,
yet
so
yeah
long
way
to
go.
So
we
can't
wait
this
long
for
this,
so
the
idea
is
to
just
use
just
yeah
some
other
transport,
so,
for
example,
currently
what
the
wasn't
buying
gem
is
using,
which
is
a
tool
for
binding,
creating
bindings
from
wasm
to
javascript.
A
They
just
exchange
it
with
a
serialized
json.
If
you
have
objects
which
is
obviously
not
such
a
good
idea
or
like
it's
super
error
prone
and
not
fast
at
all
and
so
on,
so
we
probably
use
something
else
and
then
also
michael
prototyped,
simple,
dag
and
I
sadly
didn't
find
the
time
for
doing
this
properly
today.
But
I
don't
want
to
wait
till
next
week,
so
eric
actually
brought
up
when
I,
with
the
conversation
with
him
that
like
how
is
this
different
from
from
seaborn?
A
A
The
deck
sea
was
big
stricter.
So
if
you
have
this
strictness
yeah,
it's
super
simple.
A
Basically,
it's
even
simpler,
so
you
have
so
you
have
less
code
because
you
don't
need
variance
because,
like
seaboard
does
its
own
version
of
balance
kind
of
so
it's
really
like
anyway.
I
will
finish,
wouldn't
that
be
more
code
implemented
now
no
like,
I
would
just
like.
I
would
just
finish
it
and
just
basically
it's
really
to
see
that
like
what
are
the
differences
and
like
it's
yeah,
it's
it's
kind
of
mind-blowing,
as
I
said.
I
hope
I
had
it
for
today,
but
I
didn't
finish
but
yeah.
A
It's
super
fun
and
we'll
see
and
can
use
this
as
for
further
discussions.
A
But
what
I
think
about
doing
is,
I
will
probably
use
this
stricter
dex
keyboard
as
a
basis
for
the
wasm
exchange
format,
but
we'll
see-
and
what
I
also
will
do
is
because
I
even
got
asked
today
on
the
rast
ipfs
chatroom
about
what's
the
deal
with
rust,
marty,
hash
and
the
release
and
so
on.
So
I
want
to
really
get
the
rust
materials
release
out.
A
I
will
make
prs
for
a
cd
p2p
and
live
ipod,
just
to
make
sure
it
works
and
if
it
works,
then
I
do
the
release
and
then
update
the
prs
and,
to
my
surprise,
li
p2p
was
just
using
multihedge
just
at
the
single
place
like
a
half
a
year
ago,
and
now
they
use
it
multiple
places.
So
it's
more
work
than
I
thought,
but
still
yeah.
It
should
be
straight
forward
and
I
hope
to
get
this
done
this
week.
C
E
C
D
D
D
There's
also
a
call
tomorrow,
which
is
going
to
be
in
24
hours
and
20
minutes
about
some
changes
to
the
ham
spec
that
we've
been
talking
about
for
a
while,
such
as
I
think
one
of
them
was
merged
already
changing
the
hash
algorithm
from
a
string
to
an
integer.
D
But
there
are
a
bunch
of
others
that
we
spoke
about,
but
we
didn't
actually
commit
to
doing
so.
Hopefully,
in
the
call
we
can
actually
file
issues
and
get
them
done,
and
then
lastly,
I
really
want
to
get
going
on
the
hand
compliance
tests
so
that
I
can
reuse
those
with
with
rod
instead
of
copy
pasting
tests
from
javascript.
I'm
just
redoing
work
between
the
two
of
us.
It
doesn't
have
to
start
immediately,
but
I
think
the
sooner
I
can
help
with
that,
the
better
long
term
and
yeah
that's
pretty
much.
It.
C
Gotta
go
back
to
the
damn
thing:
I've
got
it.
I've
got
it.
I've
got
it.
I
got
it!
Okay,
all
right!
Okay!
I
I
finished
up
the
multi-format
block
interface,
so
we've
been
talking
about
moving
the
the
ipld
block
interface
over
for
a
while
in
a
lot
of
conversations
with
gozala.
We
kind
of
realized
that
we
could
pair
this
down
to
something
that
was
small
enough,
that
it
could
actually
be
a
base
type
in
multi
formats
and
not
not
something
higher
level.
There
doesn't
need
to
be
a
codec
registry.
C
There
doesn't
need
to
be
all
this
other
stuff,
so
we
got
that
down
to
like
a
really
clean,
tiny
interface.
Now
that
I
really
like-
and
it's
really
kind
of
open
for
other
people
to
build
other
implementations
of
it
that
are
still
totally
compatible
and
compliant
and
other
utility
libraries
on
top,
which
maybe
the
ipld
block
interface
just
becomes.
But
after
I
got
that
in
with
a
lot
of
help
from
gozala
I've
I
wanted
to
dog
food.
C
It
was
something-
and
I
had
this
little
idea
in
my
head
for
like
a
little
key
value
store.
That's
basically
just
it's
just
sugar
on
top
of
ham
like
there's,
nothing,
there's
no
fancy
ipod
work
other
than
just
a
hand,
but
it's
kind
of
interesting
to
just
explore
this
space
of
well.
What
does
it
look
like
to
just
make
sugar
and
pretty
javascript
apis
on
top
of
creating
a
little
key
value,
store,
that's
enhanced
and
that
actually
turned
out
to
be
like
a
really
cool
little
library
that
I'm
really
happy
with
so
one.
C
The
new
block
interface
is
quite
nice.
I
do
like
it.
It
worked
really
well
for
this
case
and
also
like
this
is
something
that
we
should
probably
just
port
to
other
languages,
because
it
without
any
new
work
beyond
a
hampton.
So
once
we
have
a
hampton
working
in
a
language
like
we're
good,
once
we
we'll
do
the
hampton
we
can
actually
like
you
know,
create
a
little
database
and
start
to
think
about
like
okay.
C
What
would
cool
sugar
look
like
and
go
or
in
rust,
for
you
know,
working
with
links
or,
for
you
know,
mutating
a
database
like
how
do
you
want
to
expose
that?
And
what
do
you
return
and
things
like
that?
So
there's
a
little
library
called
dkv
distributed
key
value
store
and
it's
just
on
ipfs,
so
you
bring
up
an
ipfs
instance.
You
pass
it
in
and
then
you
just
have
like
a
nice
to
work
with
key
value
store
on
top
of
ipfs.
It's
pretty
sweet
and
yeah.
C
Now,
I'm
I'm
still
sort
of
figuring
out
like
what
the
ipld
block
interface
should
be,
and
if
we
need
it
or
not,
there's
certainly
some
stuff
that
it
used
to
do
that.
We
don't
do
anymore.
You
know
there
was
a
lot
of
lazy
loading
stuff.
There
was
some
safety
stuff
in
there
that
we
did
for
immutability,
so
I'll
probably
create
some
new
interfaces
in
there.
I
just
want
to
actually
have
these
problems
and
really
be
dealing
with
them.
C
When
I
go
to
do
that
and
not
kind
of
hypothesizing
about
what
I
might
need
to
do,
I
was
kind
of
impressed
that
I
made
it
through
the
whole
dkb
library
without
really
needing
anything
other
than
the
base.
So
I
think
I'll
probably
go
through
and
update
some
of
dag
db
and-
and
there
I'll
probably
find
some
cases
where,
like
I
do,
want
a
little
bit
more
utility
on
top
of
the
the
base
types
and
and
that's
what
the
ipod
block
library
will
become,
and
the
saga.
G
So
I'm
going
to
break
my
recent
trend
and
just
talk
about
doc,
stock
stock
stocks,
and
then
this
last
week
we
had
a
good
number
of
us
here
on
this
call
a
new
meeting
to
try
to
synchronously
push
through
some
more
docs
and
spec
stuff,
and
that's
probably
just
a
ball
that
we're
going
to
start
to
get
rolling
slowly.
But
I
hope
more
so
in
the
future.
G
Most
of
what
I'm
going
to
try
to
do
in
the
coming
week
is
do
more
work
on
enumerating
documentation
that
we
know
we
need,
because
there
is
plenty
of
it
and
then
figure
out
how
we're
going
to
track
that
together,
probably
just
starting
with
more
github
issues,
but
it
seems
like
maybe
we're
going
to
need
some
tagging
mechanisms
to
break
these
things
down
more.
I
don't
know
we'll
see.
G
We've
had
a
lot
of
discussions
to
date
about
string
specifications
and
all
of
the
possibly
entangled
components.
It
touches
on
everything
from
how
we
talk
about
the
definition
of
maps,
to,
of
course,
the
basics
of
like
where
values
actually
appear
in
leaf
nodes
of
large
blocks
of
data
to
how
we
path
over
things
and
just
generally,
what
our
interfaces
look
and
feel
like
in
various
languages
and
what
our
range
of
future
support
is.
So
it's
a
really
big
hairy
problem
and
I'm
finding
that
I've
I've
published
exploration
reports
as
gifts.
G
I
just
found
one
that
was
published
in
like
june,
and
it
actually
has
content
dated
from
like
the
third
month
of
the
year.
This
has
been
a
really
long
rolling
discussion,
so
hopefully
some
more
documents
will
come
out
soon
and
they
can
lead
us
towards
a
resolution.
I
hope
we'll
see
that's
my
week.
B
There
was
some
holiday
stuff
in
there,
but
what
have
I
got?
Okay,
so
I
did
a
little
bit
more
on
the
go
dog
pb
stuff.
This
is
partly
an
exercise
in
maki
using
what's
in
my
head
about
dagpb,
while
I
have
it
for
the
go
stuff
and
partly
additional
familiarization
work
with
ipld
prime
just
to
make
sure
I'm.
B
You
know
at
least
attempting
to
keep
up
with
the
stuff
that's
going
on,
and
this
is
the.
How
do
you
write
a
codec
in
ipld
prime,
is
quite
an
interesting
exercise
for
me
at
least
anyway.
So
that's
been
educational
and
there's
stuff
about
with
dag
pb
not
being
like
json,
which
are
these
codecs.
That
can
support
the
whole
data
model,
and
so
they
can
instantiate
nodes
of
all
the
different
types.
B
Dag
pb
supports
a
particular
shape,
so
essentially
you
have
to
instantiate
into
a
schema,
driven
set
of
nodes
and
the
other
way
in
as
well.
You
have
to
only
accept
the
that
type
of
of
data,
so
just
learning
about
how
to
transform
into
the
schema
driven
stuff
and
back
again
and
use
that
for
validation
rather
than
rather
than
writing
all
the
validation
again,
because
it's
already
in
the
schema
it's
already
in
the
schema
gen
code,
and
so
my
first
attempt
was
started.
Writing
all
these
validation
rules-
and
I
was
thinking,
hang
on
a
minute.
B
This
is
all
done.
I
don't
want
to
rewrite
this
stuff.
This
is
done
by
the
code
gen,
so
I
was
pointed
in
the
right
direction
on
that.
I
think
I
I
did
some
weekend
hacking
on
my
seaboard
handling
library.
I
michael
pointed
out
to
me
last
week
that
ghazala
is
going
to
be
soon
he's
volunteered
to
replace
the
ipld
stack
in
ipfs
with
our
new
stuff
and
and
then
so.
B
There's
an
opportunity
there,
a
little
window
of
opportunity
to
get
in
our
as
much
of
our
new
pieces
that
we
want
and
one
of
the
pieces
is
the
seaborce
which,
which
the
more
I
dig
into
our
seaboard
handling
the
more
you
know
dark
corners,
I'm
going
to
cover,
as
I
shared
yesterday
in
slack
with
all
these
superpowers,
that
our
javascript
seaboard
library
has
that
it
really
shouldn't
do,
and
so
I
I
just
was
tinkering
that
on
the
weekend
and
that's
actually
really
close
to
just
being
able
to
drop
in
into
our
sibor
daxybore
library.
B
So
I've
just
got
to
do
a
little
bit
of
cleanup
work
around
the
handling
of
the
the
final
bite
chunks
of
encoded
forms,
but
in
terms
of
its
paneling
of
all
the
seaboard
we
care
about
the
basics
are
all
there.
B
I
just
need
to
go
back
and
deal
with
some
of
the
strictness
stuff
that
we've
been
agreeing
on,
so
that's
actually
in
a
good
place,
which
is
good,
and
I
don't
really
know
what
the
priority
level
for
that
is.
But
I
imagine
gizelle
is
getting
itchy
to
start
pulling
apart,
ipfs
and
putting
this
new
stuff
in
so.
C
She
had
a
call
so
today
in
the
core
implementations
group:
gozola
wasn't
there,
but
alex
was
there
and
alex
said
that
he
wanted
he.
He
does
want
to
move
to
the
new
stuff,
but
he
wants
some
help
and
I
said
like
yeah:
like
goes
all
I
want
to
do
too.
We
should
all
just
have
a
call,
so
I
think
I'll,
probably
pitch
in
a
little
bit
too,
but
it'll
be
like
kind
of
a
group
effort
with,
because
all
and
myself
and
alex.
B
So
I
had
a
discussion
with
there's
been
some
pull
requests
coming
in
on
some
of
the
go
libraries
that
overlap
with
our
work
and
they're
just
going
unanswered,
and
this
is
partly
mainly
due
to
the
fact
that
the
go
ipfs
team
has
been
shrunk
to
like
one
or
two
people,
and
leadership
is
no
longer
there,
like.
The
original
leadership
is
no
longer
there.
So
these
pull
requests
like
getting
the
dag,
dag
kodak
into
go,
see
id.
B
You
know,
there's
crickets,
so
I
just
had
a
conversation
with
the
go
folks
about
that
about
ownership,
and
what
I
really
wanted
was
for
a
dean
to
step
up
and
say
yeah
I'll,
just
take
over
this
stuff,
but
he's
you
know
obviously
doesn't
really
want
to.
But
where
we
landed
was
he
identified
five
libraries
that
he
thought
clear.
B
Clearly,
ipad
ld.
I
don't
really
want
us
to
take
full
responsibility
for
these
things,
because
we're
trying
to
move
to
a
new
stack
and
obviously
eric,
doesn't
want
to
care
about
them
either.
B
But
I
also
don't
want
to
see
these
things
go
stale
for
open
source
contributors,
because
that's
nothing
worse
than
showing
up
with
lots
of
work
and
not
getting
anything
done,
not
getting
any
responses.
So
I
suggested
that
we
could
take
on
some
basic
mobile
maintenance
work
at
least
responding
to
pr's,
maybe
doing
some
basic
things
like
maybe
switching
the
github
actions
for
some
of
these
things,
because
right
now
there's
a
pull
request.
B
Yeah,
so
I
can't
because
I've
tried
rerun
and
then
I
and
it
doesn't
do
anything
and
then
I
go
to
the
details
page
and
says
you
don't
have
access
to
this,
so
I
can't
rerun.
So
I
told
the
contributor
I
said:
okay,
just
just
refresh
the
commit
and
push
it
again
to
trigger
it
again
and
it
won't
trigger
so
we're
just
locked
in
this
state
of
nothingness,
so
I'm
gonna
ping
it
in
about.
I
was
just
doing
that
now,
just
pinging
it
into
which
repo
the
go.
It's
ghost
cid
pull
request.
B
C
So
a
dean
thinks
that
we
that
he'll
he'll
have
he
might
be
able
to
start
working
on
updating,
go
ipfs
to
god.
Please,
prime
in
q1-
and
I
mentioned
that
peter
and
eric
had
looked
at
that
and
had
you
know,
put
together
like
a
whole
graph
of
where
things
were
going
up
before
everything
got
moved
around
in
terms
of
people
and
priorities.
So
he
made
ping
y'all
about
that.
I
I
and
he
also
wanted
better
github
actions
stuff
and
I
sent
daniel
his
way
he's
right
as
well.
So.
B
Some
stuff
there,
with
the
ghost
cid
in
particular
to
I've,
been
pulling
daniel
into
review
go
code,
but
with
go
cid
like
the
test,
wouldn't
even
run
on
go
1.15,
so
just
pull
requests
into
go
cid
to
update
that
just
a
minor
fix
and
but
at
the
same
time
be
nice
to
just
update
the
test
run,
but
so
that
the
dependencies
of
these
things
are
really
interesting.
So
like
go,
cid
is
used
by
ipld
prime.
I
don't
know
if
there's
any
thought
of
replacing
them
in
the
future.
B
G
Yes,
I
may
even
have
active
drafts,
it's
just
a
terrifying
thing
to
actually
launch
into
because
of
a
high
degree
of
dependency.
It's
unclear
if
that
would
actually
be
a
smooth
idea.
C
G
C
G
It's
going
to
be
scary
and
go
too
because
I
know
we've
already
had
conversations
in
the
go:
ipfs
implementation
details
where
used
as
map
keys
in
some
of
the
internals
as
well
and
so
like
how
it
interacts
with
even
garbage
collection,
and
things
like
this
is
actually
pretty
whether
pointer
quality
works,
also
relevant.
It's
it's
hairy.
It's
very
airy.
B
And
then
we've
got
those
questions
about
that.
Dana
was
raising
about
codex
and
having
constants
for
some
of
these
codecs.
Currently
they're
split
between,
like
we've,
got
codecs
in
go
cid
and
hash
constants
in.
I
think
it's
go
multihash.
B
B
You
know
going
merkeldag
is
one
of
the
most
ancient
parts
of
this.
I
think,
and
yet
it's
still
a
critical
path
for
active
work,
and
while
I
have
a
new
gop
dagpb
stuff
that
could
potentially
replace
that
it's
one
of
these
very
sensitive
ancient
structures
that
you
sort
of
don't
just
want
to
trivially,
swap
out
with
some
new
code
so
and
go
up
in
the
format
and
go
up
your
seaboard.
These
things
that
they
show
up
everywhere.
Every
time
iple
is
touched
in
go.
B
These
things
are
pulled
in
for
creating
blocks
they're
in
every
test,
fixture
like
the
car
library,
the
leans
on
these
go
car,
lend
on
all
of
these
things
really
deeply
so
they're
not
going
away,
but
they
need
to
be
cared
for
in
a
way
that
doesn't
make
them
look
like
they're
abandonware,
and
so
that's
my
main
concern
here.
B
So
I
think
I
think
we're
at
it's
just
an
agreement
that
the
ipld
team
and
I'm
willing
to
put
my
hand
up
for
this
as
the
primary
person,
because
I
know
eric
doesn't
want
to
and
daniel,
I
hope
will
participate
as
well.
We'll
take
some
role
in
just
making
them
at
least
look
like
they're,
not
abandonware.
B
So
there's
that
now
I
yesterday
I
wrote
up
a.
I
did
a
brain
dump
of
my
my
stack,
my
mental
stack
of
where
I'm
at
and
what
I'm
doing,
because
I
feel
like
I
keep
on
showing
up
and
doing
these
things
that
look
random,
but
it's
not
it's
not
random.
There
is
actually
a
method
to
madness
of
what
I'm
doing,
and
it
still
all
does
go
back
to
this
whole
test
fixture
plan.
B
So
I'll
just
quickly
give
you
my
stack,
my
mental
stack
and
that-
and
I
literally
have
this
in
my
head.
This
is
this:
there's
a
stack
and
I'm
sort
of
trying
to
unwind
it,
but
then
I
sort
of
go
down
again
and
and
then
I
find
something
else
that
sort
of
lies
in
there.
Okay,
so
the
test
fixture
thing
that
one
of
the
top
line
items
is
is
car
files
and
car
files
are
not
absolutely
essential
for
getting
this
stuff
done.
B
It's
just
that
car
files
are
a
really
nice
part
of
it
because
they
allow
you
to
bundle
your
fixed
fixtures,
but
also
bundle
additional
data
that
might
contribute
to
your
test
running.
So
if
you've
got
a
setup
environment,
you
need
to
start
from
a
particular
state.
You
can
just
put
them
all
in
a
car
file,
so
car
files
are
like
this
nice
enclosure
for
having
this
thing
running.
B
So
I
just
wanted
to
get
car
files
running,
but
the
javascript
car
file
library
is
was
pinned
onto
this
javascript
stack
that
the
michael's
initial
rewrite
of
the
stack
and
that
has
now
been
blown
away
with
gazala
and
michael's
new
stuff,
and
so
it's
like
there's
a
rewrite
needed,
but
at
the
same
time
the
whole
interface
has
just
been
garbage.
B
I
tried
to
use
the
the
data
store
interface
interface,
that
the
all
the
old
javascript
stuff
was
using
and
it's
just
such
a
terrible
fit
and
everything
feels
clunky
and
it
makes
the
internal
clunky.
So
at
the
same
time
I
was
working
with
gaza
to
I
have
been.
This
is
still
an
active
project.
This
again
is
in
my
stack
of
designing
new
interfaces
to
generic
block,
storage
and
sort
of
working
on
this
space
of
where
you
put
blocks
and
how
you
want
to
interact
with
them.
B
We
have
a
pretty
good
plan
and
I've
implemented
most
of
it
in
that
process
that
all
of
my
test
fixtures
for
the
car
library
they
sort
of
mirror
what's
going
on
in
the
go
car
library
and
they
pull
in
all
these
codecs
to
do
like
just
to
try
out
different
codecs
and
dag
pb
has
been
the
standout
problem
in
that,
because
dag
pb
has
not
been
updated
to
any
of
the
new
stack
in
javascript.
It's
like
we're.
Still
using
this.
We
have
been
using
this
ancient
dag
pb
stuff
that
nobody
has
wanted
to
touch.
B
So
I
I
decided
to
touch
that,
which
is
how
I
ended
up
in
dag
pb,
which
is
how
I
discovered
that
it
was
a
much
bigger
rabbit
hole
than
I
thought
it
was.
It
was
in
in
the
beginning,
which
resulted
in
all
those
the
spec
changes
for
dag
pb
and
the
strictness
stuff
and
then
eventually
a
rewrite
all
the
way
down
to
the
encoding
and
decoding,
and
we
now
have
a
new,
dag,
pb
javascript
codec
in
that
we
can
use.
B
B
So
that's
why
I've
been
working
on
the
go,
dag
pb
stuff,
not
because
it's
critical
path,
but
simply
because
I'm
in
there
and
it'd
be
nice
to
have
that
done
and
also
looking
at
dag
now
go
ipld
prime
proto,
which
has
quickly
become
critical
path
for
far
coin
still
using
the
old
dagp
stuff
in
go,
which
has
all
of
these
strictness
problems,
which
has
all
of
these
ways
that
you
can
there's
almost
infinite
ways.
You
can
use,
do
same
data
different
cid
for
dag
pv,
so
it'd
just
be
really
nice
to
sort
that
out.
B
So
that's
one
of
the
reasons
I'm
on
deck
bb
and
then
at
the
same
time.
It's
this.
You
know,
while
I'm
there
trying
my
hand
at
go:
ipld,
prime
codex,
that
stuff's
not
super
critical,
but
it's
sort
of
part
of
that
stack
and
I'm
trying
to
unwind
that
the
other
thing
is
I
I
I
need
jason
to
work
for
this
stuff
and
I
just
assume
that
jason
is
good
ready
to
use,
which
is,
of
course,
naive,
of
course.
Now.
B
I
know
that
it's
naive,
because
I
want
to
be
able
to
author
these
things
in
doug
jason,
and
I
also
would
really
like
to
be
able
to
have
simplified
versions
of
these
things
that
are
just
dag
json,
like
you
can
dump
in
json
into
a
test
file
and
it
just
and
you
can
copy
and
paste
json
and
what
would
be
really.
Nice
is
also
a
a
loose
form
of
jason,
and
I
was
I've
been
throwing
around
the
idea
of
a
dog
jason,
pretty,
which
is
a
pretty
printed,
dag
jason.
B
That
actually
would
look
nice
in
tests.
But
it's
a
agreed
codec
that
works
across
our
different
stacks.
That
is,
is
fairly
easy
to
implement
in
theory,
so
it's
anyway,
so
it
turns
out
that
it's
not
it's
not
at
all
straightforward.
So
this
is
another
reason
to
be
in
the
codec
layer
of
go.
B
B
The
two
big
expect
questions,
one
of
which
I'd
like
to
be
able
to
resolve
today
is
about
this
tokenization
thing
about
you've
got
to
get
deep
into
the
maps
in
order
to
determine
whether
or
not
you're
dealing
with
bytes,
and
when
you
find
that
you're
not
dealing
with
it,
because
you've
got
some
extraneous
property
or
something's.
Not
quite
right.
B
Do
you
have
to
reuse
all
those
tokens?
Or
can
you
reject
the
block
at
that
point
because
it's
not
properly
formed
in
the
javascript
we
just
effectively
rewind
and
reuse
and
say:
oh,
that's,
not
bytes,
but
I'll
interpret
that
as
just
data
model
map
in
map
in
go
it's
more
complicated
because
you're
dealing
with
tokenization
and
eric's
been
buffering.
B
I
think
it's
six
tokens
and
it's
it's
a
matter
of
what
you,
what
you
do
with
those
six
tokens
when
you
find
this
at
the
sixth
element,
that
it's
not
right,
do
you
have
to
then
unwind
and
then
reuse
them
properly
or
do
you
get
to
say
nah,
that's
garbage,
reject,
that's
an
interesting
question
that
needs
resolving.
I
don't
really
want
to
resolve
that
today,
because
it's
complicated.
What
I
would
like
to
resolve
is
this
other
question
of
multi-base
and
base64.
So
eric's
initial
implementation
was
just
doing
base64
encoding.
B
Why
do
we
have
a
multi-base
prefix
in
there
and
I'd
like
to
propose
that
we
don't
have
a
multi-base
prefix
that
we
just
do
base64
and
ditch
multi-base,
because
there's
no
good
reason
for
it
unless
we
think
we're
going
to
add
different
bases
in
there,
which
then
blows
away
the
whole
same
data
that
once
same
codec
for
same
data
thing
like
we
can't
vary
the
base.
It
just
has
to
be
base64.
C
Yeah
there
was
that
discussion
actually
is
on
github.
That
happened
that
didn't
happen
somewhere
else,
so
you
should
be
able
to
find
that
thread.
I
honestly
don't
think
that
we
discussed
it
that
much.
We
spent
most
of
the
time
discussing
what
the
multi-base
should
be
for
cid
and
it
was
just
sort
of
like
oh
yeah,
we'll
do
multi-base
64..
I
don't
remember
why
we
felt
it
was
important
to
do
the
prefix
in
there,
but
that
that
was
actually
a
change
that
was
made.
A
Yeah,
like
I,
I
think
I
did
the
change,
if
I
recall
correctly,
so
I
was
in
favor
of
using
multi-base
but
yeah.
I
don't
think
it's
a
good
idea
anymore.
So
so
I
also
can't
can't
recall
why,
but
I
basically,
I
guess
I
thought
well,
why
not
using
multi-base
for
it,
but
I
think
yeah
the
the
argument
that
we,
so
I
think
multi-base
makes
it
really
make
sense
if
you
want
to
use
different
multi-bases.
A
B
A
I
think
it
it
might
break,
it
might
break
the
rust
frycoin
test
stuff,
but
I
will
check
up
with
austin
to
make
sure
it
like,
like.
I
am
happy
to
provide
a
pr
fixing
this.
So
it's
like
it's
not
a
video
like
it's
yeah.
B
Yeah
and
the
other
thing,
the
other
thing-
that's
not
in
my
list.
There
is
the
this
white
space
handling
in
go,
that's
not
that
needs
to
be
cleaned
up
as
well.
So
just
basically
we
need
go
work
here.
So
so
my
proposal
is
we
get
these
things
sorted
out.
So
the
multi-base
thing:
let's
do
that
in
the
specs
repo,
the
tokenization
thing
I'd
like
to
maybe
to
do
some
more
exploration
on
that,
and
my
suggestion
is
daniel,
because
you're
relying
on
me
to
get
a
lot
of
this
stuff
done.
B
Maybe
something
that
you
could
shift
to
is
helping
me
get
go
dag
jason
up
to
spec
and
because
your
expertise
is
also
in
json.
So
this
seems
like
it's
perfect,
for
you
get
that
up
to
spec
and
so
that
we
can
have
we
have.
We
have
an
implementation
that
we
know
is
one-to-one
between
the
languages
and
then
we
can
use
this
as
a
because
one
of
the
things
I'd
like
to
do
with
these
test.
B
Fixtures
is
also
test,
our
codecs
with
them,
and
if
we
have
no
codec,
like
none
of
our
codecs
agree
tag
pb
is
the
closest
codec.
That
agrees
between
our
languages
right
now,
but
nothing
else
agrees,
and
so
we
need
to
sort
this
stuff
out.
So
that's
my
suggestion.
C
If
you
fix
the
the
white
space
stuff,
then
I
think
that
also
ends
up
fixing
your
tokenization
problem,
because
then
you
can
just
treat
the
entire
prefix
before
it
as
the
token
right.
So
it's
not
so
if
you
see
an
open
bracket,
you
just
check
if
the
rest
of
it
is
open
bracket,
slash
blah
blah
blah
base64
and
then
that
just
because
that
whole
section
of
bytes
just
becomes
the
entire
token
for
saying
what
is
base64.
B
Pieces
here
where
you've
got
to
reach
down
to
a
peak,
but
my
my
suggestion
is
that
this
might
be
something
that
that
daniel
can
look
at
the
complication
of
doing
that
kind
of
pick
because
yeah,
that's
a
nice
solution,
but
we've
got
layering
concerns
here
where
these
token
that
tokens
are
being
embedded
from
refund
right
down,
deep
and
so
to
do
a
peek.
B
You
need
to
go
right
down
into
the
stack
and
it's
sort
of
overriding
this,
this
layering,
which
is
complicated.
So
this
might
be
something
for
daniel
to
look
at.
Maybe
maybe
unwinding
them
is
not
going
to
be
hard.
It
just
requires
a
little
bit
of
a
refactor,
but
I
know
I
don't
think
eric
really
wants
to
be
touching
this.
I
think
eric
you.
You
threw
that
branch
up
in
rage
and
just
moved
on,
didn't
you
so,
yes,
there's
a
rage
branch
that
this
is
found
in
that
maybe
daniel
can
have
a
look
at.
B
I
would
I
actually
can
see
a
lot
of
places
where
I
would
really
want
to
use
it
and
it's
and
it's
things
like
test
fixtures,
debugging
and
printing
stuff
out
to
the
console
it
it.
It
serves
really
well
as
a
thing
that
we
can
look
at
and
understand
now
the
bytes
and
the
cids
are
a
problem,
but
it's
at
least
something
so
yeah
anyway.
That's
me
thanks
for
bearing
with.
E
Yes,
I
have
stuff
to
say
by
the
way
I
love
how
your
short
week
I
was
busy
with
the
kids
turns
into
you,
know.
E
I
know
yeah
so
just
a
comment
before
I
dive
into
my
stuff.
The
reason
me
and
eric
didn't
get
anywhere
with
ltd,
prime
in
ipfs.
It's
not
because
other
stuff
came
up
it's
because
it's
like
really
tricky
to
move
anything
anywhere
exactly
because
what
you're
describing
that
everything
is
depending
on
everything
and
all
of
that
is
super
gnarly
and
so
on
and
so
forth.
So
on
that
note
what
I
worked,
I
peel
this
on
this
weekend.
E
Actually,
because
I'm
doing
I
don't
have
time
for
that
is
to
get
an
actual
lotus
on
the
actual
test
net
running
against
an
actual
sql
database
sqlite
in
this
case,
so
I
literally
have
something
that
syncs
keeps
the
chain.
Does
everything
correctly
stops
starts?
You
know,
exports
and
so
on
and
so
forth.
This
is
essentially
my
gateway
to
give
you
guys
a
chain,
because
nothing
else
scales
to
what
we
need.
The
sentinel
team
is
having
the
very
same
problems,
and
hopefully,
actually
some
some
of
this
work
will
be
useful.
E
We
already
is
adapting
some
of
it.
The
problem
is
this:
even
the
very
recent
state
of
basically
finality
which
is
900
blocks,
turns
into
17
million
blocks.
Just
for
you
know
just
for
basically
about
seven
hours
of
state,
then
that
chain
I
haven't
imported
anywhere
yet,
but
it's
going
to
be
another
opening
to
two
orders
of
magnitude.
More
than
that
which
means
that
stuff,
like
the
s3
datastore,
is
out.
E
So
I
basically
went
oh
michael,
it
gets
so
much
better,
so
I
went
like
okay.
I
just
need
a
blog
store
here.
That's
all
I
need,
and
I
literally
need
my
blogs.
So
how
hard
can
it
be?
It's
five
methods
to
implement
this
interface,
so
the
first
method
is
list,
every
single
block
that
you
have
no
pagination,
no
limits
nothing,
and
this
is
something
that
needs
to
run
on
every
startup
of
lotus,
regardless
of
how
big
the
chain
is.
E
So
that's
that's
number
one
that
was
a
little
bit
difficult
to
to
to
to
figure
out
with
transactions
and
stuff
like
that
and
locking,
but
you
know
that
that's
not
working
super
slow,
still
and
I'll
have
to
bring
it
up
with
lotus.
After
after
after
we
launch
like
how
we
sh,
we
stop,
you
know
scanning
the
entire
thing.
Basically,
that's
better.
Do
you.
E
I
E
E
E
Yes,
it
could
be
worse.
Everything
can
be
worse,
that's
true!
Well,
I'm
just
getting
started
so,
okay,
you
stream
them
in
you,
do
stuff
with
them
and
I'll
get
back
to
this
myth
in
a
moment.
So
then
it
took
me
like
almost
six
hours
together
like
why
my
stuff
doesn't
work,
because
it's
just
a
block
store.
You
just
have
you
know
a
column
for
the
key
and
account
for
the
data
and
nothing
works.
It
turns
out.
E
If
you
recall,
I
mentioned
that
there
is
like
a
bunch
of
layers
and
the
bottom
layer
along
the
bottom
layers
is
the
ipfs
datastore.
E
E
Now
this
thing
that
I
was
talking
about
that
stream
stuff
out
it
actually
doesn't
have
like
the
normal
block
store,
doesn't
even
have
this
coded
information,
so
you
stream
out
cids
by
just
slapping
like
raw
on
all
of
them,
regardless
of
how
they
came
in
the
into
the
block
store
originally
so
this
list
everything
lists
rossi
ideas,
but
when
you
store
and
when
you
retrieve
you
might
be
getting
sibo
or
you
might
not.
So
there
is
some
comment
in
in
the
in
the
links
that
I
left
about
this
as
well.
E
Now
there
is
another
problem,
the
hold
up.
What
what
was
the
third
thing.
E
E
E
So
all
that
to
say
yeah
we
essentially
have
a
change
that
is
absolutely
dependent
on
multicast
comparison
right
now
and
I'm
not
even
sure
we'll
be
able
to
unwind
this
correctly.
But
that's
my
exploration
report.
E
Well,
that
order,
if
you
use
something
like
sql,
you
just
turn
on
phantom
reads
and
again
it
might
be
else.
Girls,
sqlite
specific,
that
my
login
wasn't
correct
because
it's
like
really
difficult
to
get
it
even
to
run.
H
E
I
C
E
The
best
part
yeah,
the
best
part,
is
that
lotus.
You
know
still
has
some
memory
issues
here
and
there.
So
whenever
you
own
a
lotus,
you
kill
nina
badger,
which
means
that
you
know
we
have
about
20
percent
chance
that
you
destroy
it
and
yeah.
We
have
a
number
of
people
in
falcons
like
basically
say:
okay,
so
you
go
to
this
director.
You
delete
this
stuff.
You
sync
your
chain
from
here.
Again,
that's
normal
operation.
C
E
H
Rough
so
peter-
I
guess
relating
to
that.
I
I
don't
know
if
you've
looked
at
the
car
block
store
interface
that
I
packed
together
to
directly
use
the
car
as
a
read-only
block
store
and
put
an
index
at
the
end
of
it.
I
did
a
little
bit
more
on
that
last
weekend
I
have
a
b
tree
based
index
as
well
as
just
using
a
dumb
map.
H
If
I
have
a
sorted
list
of
all
the
sids
to
their
bite
offsets
in
the
car
file.
As
the
index
that
I
use
the
index
is
actually
a
little
bit
bigger,
which
I
wasn't
expecting
compared
to
just
using
goes
basic
map
type
of
mapping
sids
to
index,
and
maybe
that's
because
it
compresses
it
or
something
I
don't
know,
but
look
up
seem
similar
speed,
maybe
a
little
faster,
arguably
on
the
b3
lookups.
So
maybe
that's
better
awesome.
You
can
do
either.
H
E
My
use
case
is
actually
a
little
bit
different
because
I
need
to
be
to
have
something
that
continuously
updates
stuff
correctly
without
shutting
anything
down,
and
that's
basically
where,
in
in
the
final
version
of
this,
there
will
be
a
postgres
that
is
being
run
again
against
which
a
lotus
runs
and
then
other
things
read
into
that
view
as
many
times
as
they
want.
And
basically
I
can
even
spin
up
this.
H
E
You
can
buy
this
stuff
without
without
turning
on
the
actual
demon
button
in
the
networking
that
I
just
linked,
where
you
basically
just
created
this
offline
state
yeah.
H
Stopped
passing
that
so
I
was
I
was
delving
into
this.
I
saw
that
there
were
basic
places
where
you
could
have
a
read-only
repo,
and
then
there
was
just
really
nothing
using
that
anywhere.
So
someone
had
thought
about
it,
but
there
really
wasn't
much
proof
of
this
being
a
viable
solution,
but
if,
if
you've
gotten
it
to
start
up
and
be
happy
with
that,
that's
awesome.
H
The
other
thing
that
we
were
talking
about
very
briefly
when
we
were
considering
our
options
last
week
on
sentinel
was:
could
we
just
run
lotus
on
like
a
zfs
or
some
sort
of
file
system
with
snapshots
and
then
use
the
file
system
snapshot
mechanism
to
save
you
know
a
consistent
snapshot
and
use
that
as
a
read-only
view
of
the
badger
or
whatever
data
store,
while
the
lotus
keeps
going,
I
think
that's
probably
potentially
a
path
of
really
not
too
bad
resistance,
but
it
does
mean
everything's
on
the
same
node.
E
And
for
everybody
else
on
the
call
why
this
is
important.
Actually
there's
another
thing
in
lotus,
where,
whenever
you
make
an
api
call,
there
is
literally
a
global
lock,
it
freezes
everything
else.
So
if
you
hit
the
api
too
much,
you
lose
sync
with
the
chain
because
cannot
catch
up.
So
that's
another
thing:
that's
the
sentient
folks
are
working
against
and
which
I'm
also
working
against
for
the
slingshot
competition,
because
I
need
a
view
that
also
hits
the
api
relatively
quickly,
but
I
need
to
like
produce
it
some
other
way
without
losing
things.
A
Yeah,
we
only
have
five
minutes
left
and
there
was
a
question
from
johnny
about
the
the
which
determined
this
thing
mapping
order.
We
use
for
taxi
bar.
J
Are
many
and
a
lot
of
people
just
cut
and
paste,
but
so
I'm
actually
finalizing
the
spec
and
there's
a
pull
request
for
the
seabor
and
representation
of
the
did
document,
and
I
want
to
make
sure
it's
in
aligned
with
what
the
determinant
is
ordering
that
is
already
existing
in
ipld?
Yes,
so
the
problem.
A
Is
that
we
currently
use
the
ordering
that
the
current
taxi
bar
spec
proposes,
with
the
first
the
I
can't
be
called,
I
think,
first
the
length
and
then
the
rest,
but
I
think
like
we
tend
to
like,
I
would
like
to
change
it,
so
we
haven't
discussed
it
yet,
but
I
totally
would
want
to
do
the
normal,
like
what
everyone
does
like.
Basically
just
mem
compare
sword
order.
A
Basically,
so
I'm
not
sure
if
it's
a
good
idea
to
put
in
there
the
current
order
that
we
use,
because,
like
I
like
I
for
myself,
would
like
to
change
this.
I
don't
know
what
others
think
about
the
seaboard
map
key
order.
C
J
Well,
I
think
canonical
is
like
we
talked
about
last
week,
is
up
to
the
implementers
of
what
you
mean
by
canonical
and
as
long
as
you
specify
it
in
your
spec,
then
it's
canonical
as
you
determined
it.
So
I'm
writing
this
back
and
so
they're.
They
want
to
close
it
within
the
next
week
or
so
to
actually
get
the
candidate
recommendation.
J
So
I
want
to
make
sure
that
I'm
not
shooting
myself
in
the
foot
and
that
it's
totally
in
line,
so
I
have
to
do
minimal
processing
to
get
ipld
in
in
conformant
with
what
I
just
wrote
and
I
pulled
it
out
of
the
air
as
far
as
what
I
copied
and
pasted
from
the
749
and,
of
course,
the
the
draft
version
they're
not
accepting
it,
it's
not
normative
so,
but
I
I
can
specify
whatever
I
want.
J
G
My
hot
takes
on
this
right
now,
not
having
have
rediscussed
the
question
with
anybody
recently
so,
like
just
claimed,
I
would
go
ahead
and
use
the
canonical
sorting
that
is
defined
by
the
seahorse
spec
right
now,
even
though
almost
none
of
us
in
this
call
me
included
like
it
very
much,
I
would
stick
with
it.
That's
what
we
originally
specified
seabor
to
be.
G
Yeah,
I
think
it's
a
worse
stuck
with
it
thing,
so
you
might
as
well
keep
with
it.
I'm
thinking
most
of
the
properties
that
show
up
in
this
did
spec
are
known
in
advance
anyway
right.
So
it's
also
we're
not
sorting
anybody's
random
string
keys
here.
Are
we.
J
Well
not
yet
right
now
it's
I'm
using
utf-8
keys,
utf
utf-8
strings
as
keys
full,
stop
which
case
that,
but
there
there
is
a
a
movement
towards
something
called
sebor
ld
seabord
link
data
where
you
use
an
external
dictionary
and
the
order
that,
based
on
that
ordering
of
the
dictionary,
in
which
case
you
could
use
ins
as
keys,
so.
J
So
that
that
and
that's
I
put
a
placeholder
in
in
the
spec
for
how
to
use
tags
to
do
this
in
the
seaboard,
but
like
most
of
it
is
to
get
to
that
cos.
A
sine
thing
we
talked
about
before,
which
is
that,
basically,
I
have
a
cid
that
I
physically
and
that
cid
is
raw,
cbor
or
or
a
payload.
That
basically
is
signed
with
as
the
payload
prepended
with
tag
42..
So
it's
mostly
it's
just
with
trying
to
get
this
to
candidate
recommendation
and
I'm
the
only
one
who's
working
on.
J
I
see
more
stuff-
and
I
think
I
mentioned
jim
shad
died
just
last
week
and
he
was
gonna
help
me
with
some
of
this
making
sure
that
he
reviewed
it
he's
the
seabor.
G
Expert,
no,
I
think
you're
on
the
right
track.
Go
with
the
utf-8
string.
Keys
like
you're
doing
sounds
good
to
me.
That
is
the
thing
that
we
are.
The
most
confident
will
be
the
least
trouble
for
any
of
our
existing
code
to
work
with
and
should
be
the
case
for
ever,
and
I
would
stick
with
the
sorting
algorithm
that
is
specified
by
that
original
seaboard
rfc,
even
if
it
makes
us
sad,
we
have
already
committed
to
it.
In
the
past
ship
sailed:
it's
fine
we're
going
to
live
with
it.
J
And
one
thing
I
would
recommend
is
take
a
look
at
the
cddl,
the
concise
data
dictionary
language,
your
data
definition,
language,
I've
been
using
it
and
I've
prefer
baking
that,
as
being
the
abstract
data
model
to
actually
get
to
lossless
conversion
between
json
and
and
cbore.
So
I've
been
writing
a
lot
of
it
now
and
actually
makes
sense
we're.
J
Actually
I
can
you
can
have
it
optional
prepended,
with
a
tag,
although
dag
keyboard
doesn't
use
the
tags
other
than
42,
and
so
I've
took
the
time
to
learn
it,
and
actually
it's
pretty
robust.
In
fact,
a
lot
of
iatf
full
specifications
are
moving
towards
cddl,
including
if
you
guys
remember
jim
pick,
and
the
woman
from
google
presented,
the
sxg
signed
http
payloads
and
she
wrote
all
that
in
cdl,
which
is
pretty.
A
Cool
all
right,
we
are
hitting
the
one
hour
mark,
and
so
I
posted
in
the
chat
the
link
to
this
zebra
spec,
where
we
specified
the
stone
order,
so
yeah
awesome
yeah.
I
actually
wasn't
aware
of
that.
We
so
clearly
specified
that's
cool
yeah,
so
yeah
is
there
anything
else,
but
I
so
I
don't
want
to
run
over.
But
if
there's
anything
urgent
then
no
it
doesn't
seem.
So
then
thanks
everyone
and
see
you
all
next
week
goodbye
everyone.