►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2020-08-31
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
B
A
Also
like
had
time
to
spend
on
ipod
stuff,
so
I
worked
on
tiny
multihash,
a
bit
which
is
a
fork
of
rust
multihash.
But
it's
planned
to
get
upstream
and
yeah.
A
I
plan
to
do
hopefully
the
merge
this
week
and
to
have
it
upstream
and
the
the
other
thing
is
then,
of
course,
you
need
to
also
upstream
rust,
cld
and
so
on,
but
so
basically
this
week
I
try
to
focus
on
getting
all
that
is
upstream
and
you
can
then
move
from
there,
because
we
also
have
the
discussion
if
we
want
to
use
mono
repo
like
approach
like
js,
is
doing
so
not
like,
like
not
like
everything
in
one
library,
so
in
one
create,
but
just
like
having
a
single
repository
for
all
the
multi
formats,
because,
like
multi,
hash
and
cid,
and
so
on,
is
often
like.
B
A
So
much
on
each
other
or
like
you
want
to
have
changes
between
them,
so
it
might
make
sense
having
a
single
repository
with
all
the
crates
in
it,
but
that's
yeah
something
I
also
want
to
discuss
with
a
broader
community
yeah
and
then
also
I
started
discussion
about
like
what
what
multi
codec
actually
means.
A
So
this
was
a
spin-off
by
also
rust
discussion
that
it
kind
of
is
like
basically,
multi-hash
is
about
hashes,
so
we
create
multi-hashes,
and
then
we
have
multi-hatches
and
kind
of.
I
please
about
codex.
So
should
the
thing
that
you
work
on
be
called
multicodec
because
it's
kind
of
like
codex
on
steroids
as
mutators
are
for
hashes,
and
it
was
just
interesting
because
I've
never
seen
it
like
this,
because
I
know
all
the
long
history
of
multicodex
and
stuff
so,
but
it
might
be
interesting
to
yeah,
discuss
the
naming
or
see.
A
If,
because
I
personally
think,
for
example,
that
multi-coding
should
be
actually
what
we
currently
call
multi-coding
should
be
called
my
decode
only,
but
I
think
we
still
should
call
the
the
other
thing.
Hyperled
coding,
but
yeah
still
is
names
and
we
should
clarify
things
and
there's
an
open
issue
that
I
was
also
linked
in
the
notes.
A
Yeah
cool,
that's
all
I
have
so
not
that
much
news.
Actually,
oh,
I
have
more
news
that
I'm.
Finally,
I've
done
a
lot
of
fire
con
work
in
the
past
few
weeks,
and
today
I
also
announced
in
the
or
like
we
discussed
in
the
falcon
meeting
from
our
team,
where
I
am
is
that
I'm
finally
back
to
only
part-time
on
file
coins,
so
I
play
plan
to
spend
about
like
a
day
worth
of
work
and
file
coin
and
the
rest
of
my
quality,
so
I'm
kind
of
like
back
to
normal
yeah.
A
A
Okay,
then,
next
on
my
list
is
danielle.
D
Also,
as
I
was
reading
the
specs
for
the
blog
format,
I
noticed
that
there's
a
way
to
encode
json
strings
in
multiple
ways
with
the
current
spec.
So
I
found
that
as
an
issue
might
not
be
high
purity,
but
could
still
be
interesting
and
that's
it
for
now
I'll
just
continue,
I
would
say
I'm
about
two-thirds
done,
understanding
the
specs,
at
least
at
a
basic
level.
D
E
Profiling,
I
spent
a
little
bit
of
time
this
week,
looking
at
reports
from
downstream
users
of
some
of
our
libraries
about
memory.
Profiling,
stuff
coin
is
looking
at
their
performance,
as
is
to
be
expected
in
that
project.
E
At
this
phase,
I
guess,
and
so
a
couple
of
pr's
have
landed
in
go
ipld,
prime,
about
reducing
allocations
and
we've
merged,
some
of
those
that
involve
mostly
just
drilling
through
abstractions
a
little
bit
like
it's
good
to
have
a
reader
and
writer
interfaces
so
that
you
have
interfaces
for
a
bunch
of
reasons,
but
then
it
turns
out
also
if
you
know
that
you
have
this
whole
byte
array
as
one
contiguous
thing,
if
you
drill
straight
through
it
needs
that
it
goes
faster
and
that's
for
your
allocs,
so
we've
started
introducing
some
drilling
through
abstractions,
like
that,
where
the
performance
seems
justified.
E
So
that's
fun.
I've
also
just
been
doing
a
bunch
of
enumeration
of
other
tasks
that
we
need
to
do
in
this
library.
In
the
last
week,
a
bunch
of
that
stuff
has
lived
in
my
head
and
that
is
no
longer
scalable.
E
Daniel
has
written
a
half
dozen
fixes
to
various
issues.
In
go
ipld,
prime,
by
the
way
which
he
didn't
give
himself
credit
for,
so
he
should
do
this
and
is
renovating
the
ci.
E
So
that's
highly
welcome
and
the
other
piece
of
interesting
news
I
have
for
this
week
is:
I
had
a
meeting
with
the
textile
and
three
box
folks
and
some
of
the
other
people
that
they're
working
with
to
develop
the
jose
and
jose
and
jose,
and
all
these
implementations
there's
somebody
now
who
is
looking
at
how
to
do
that
stuff
in
going
and
that's
really
exciting.
E
So
I
spent
a
little
time
walking
around
the
libraries
with
them
and
I
think
a
lot
of
the
implementation
choices
will
be
just
like
totally
up
to
those
developers
doing
that
stuff
and
we
didn't
really
like
make
strict
commitments
about
how
any
of
that
stuff
is
expected
to
proceed.
E
Yet
it
was
just
sort
of
like
information
exchange
a
little
bit
more
fact-finding
about
like
the
details
of
the
code
base
and
how,
like
here's,
where
the
codec
code
lives
and
here's,
where
the
other
you
know,
but
now,
they're
equipped
with
lots
of
information
about
that.
So
I'm
really
looking
forward
to
seeing
what
comes
with
that,
and
we
talked
about
a
bunch
of
different
ways.
These
things
could
be
implemented
to
maximize
the
codings.
E
It's
really
easy
to
take
that
and
just
tie
it
together
with
multi-codec
code
at
the
last
moment.
But
if
you
want
to
have
this
code
ready
to
use
as
an
adl
in
the
future,
we
might
come
up
with
interfaces
that
get
us
like
99,
if
not
100,
of
the
way
there
as
well
at
the
same
time.
So
hopefully
that's
just
winning
and
we'll
see.
F
Hey
you
another
week
of
just
being
captured
by
z,
bag.
It's
whoo,
there's
some
cool
stuff,
so
there's
a
there's,
a
very
detailed
spec
and
it
contains
pretty
much
all
of
my
ideas
and
reasoning
and
what
was
implemented
through
last
week
till
about
thursday,
and
then
I've
had
more
ideas
since
then,
including
like
some
of
the
biggest
compression
wins
that
I
think
I've
seen.
But
the
the
really
big
thing
is
that
gotten
much
better
at
explaining
it.
F
I
had
a
really
good
call
with
research,
got
some
really
good
input
from
steven
actually,
who
just
said,
I
don't
get
this
and
here's
what
I
would
need
to
understand
what
you're
talking
about.
So
I
wrote
that
wrote
a
bunch
of
more
stuff
into
the
spec,
so
it's
a
bit
more
understandable.
I
bet.
Last
week
I
sounded
like
a
crazy
person
who
hadn't
slept
because
that's
what
I
was
but
yeah
now
it's
like
actually
like
a
real
thing.
F
Also
man,
I
found
just
some
huge
huge
wins
like
like
when
you
parse
a
csv.
F
You
know,
like
you,
get
back
a
bunch
of
just
lists
of
lists
right,
like
it's
just
an
array
of
a
bunch
of
arrays
or
it's
like
an
array
of
a
bunch
of
objects,
but
just
like
the
same
keys
over
and
over
again,
all
of
the
same
size.
F
I
I
have
techniques
to
shed
just
all
of
those
tokens
like
there's
just
no
tokens
anymore.
It's
literally
like
you
can
just
encode
the
dimensions
of
the
shape
and
then,
if
it,
if
the
columns
have
the
same
type,
you
can
just
encode
the
type
once
for
the
column
and
then,
if
they
have
the
same
keys,
you
can
just
encode
the
key
deltas
once
and
so
literally,
it's
like
that
kind
of
a
structure
just
becomes
like
a
series
of
violence
without
a
closing
token,
because
you
know
the
dimensions,
so
you
don't
even
need
a
closing
token.
F
It's
really
amazing,
and
if
you
keep
the
compression
tables
below
255,
you
have
it's
actually
a
fixed
size
table,
so
you
can
skip
into
it
because
it's
you
know
that
they're
only
one
bite
pointers
yeah
so
like
if
we
design
for
this
we're
just
gonna
end
up
with
stuff.
That's
like
50
to
70
percent,
smaller
than
cbor
like
like
in
in.
I
think
the
generic
case
like
if
you
just
take
something
from
seabourn
put
it
in
this
it'll,
be
like
a
maybe
like
a
12
increase.
F
F
So
I
can
talk
about
at
the
end
of
the
call,
but
that's
basically
my
week
and
also
like
a
bunch
of
management
stuff
that
I've
had
to
do
and
yeah
that's
about
it,
though
I
don't
know
who's
next
folker.
G
Next
is
right
so
a
week
of
miscellany
in
javascript,
my
head
in
some
of
this
esm
stuff,
again:
testing
browser
stuff,
ui,
eight
arrays
versus
buffers
and
so
mostly
focused
around
the
car
repo,
because
that's
sort
of
what
what
I
was
well.
It
wasn't
my
intention
to
do
that.
This
week
I
was
meant
to
do
the
bitcoin
spec.
G
We
got
caught
up
in
this
javascript
stuff,
but
I
sort
of
angling
towards
getting
the
car
stuff
easier
to
use
so
that
we
can
work
on
some
of
this
test,
fixture
stuff
that
eric
and
I
mapped
out.
That's
the
sort
of
the
rough
goal
still
want
to
get
that
done,
even
if
we've
well,
I
mean
we
might
want
to
go
back
and
help
falcone
with
their
stuff,
but
that
was
the
original
goal
for
that.
But
it's
just
a
long-term
goal
anyway.
G
So
just
been
working
on
modernizing
that
stuff,
making
it
work
in
the
browser
used
michael's
new
tool
chain
for
javascript,
it's
all
working.
Well,
I
got
a
big
pr
merged
that
I've
linked
in
the
notes
and
I've
started
refactoring
the
whole
interface
just
the
the
data
store
interface,
which
inherits
from
an
old
thing
that
came
up
was
come
up
with
for
ipfs,
it's
just
it's
just
too
frustratingly
on
ipld
and
so
been
decided
to
bite
the
bullet
and
and
do
a
new
interface
for
that.
G
That
is
much
more
in
line
with
our
conception
of
the
the
block
abstraction.
So
I
have
an
issue
that
I'm
linking
the
notes
there
that
I
wrote
up
my
proposal
for
what
I'm
going
to
do
there.
G
So
that's
I
want
to
try
and
finish
that
out,
but
while
I'm
doing
that,
I'm
also
finding
that
what
I
might
do,
I'm
not
sure
yet
whether
I'll
do
this
just
internally
in
the
car
library
or
actually
refactor
it
more
heavily,
but
but
I'm
pulling
out
the
core
of
the
algorithm
into
a
like.
G
It
was
already
pulled
out
into
a
core
piece
like
an
encoder
decoder,
but
I'm
thinking,
maybe
that
needs
to
just
go
elsewhere,
and
so
you've
got
this
block
storage
abstraction
over
car
files,
which
doesn't
really
belong
like
car
files,
aren't
really
they're,
not
really
a
block
store
in
the
way.
You
would
normally
use
a
block
store
where
you
can
put
get
iterate
all
those
sort
of
things.
A
car.
A
flat
file
is
a
has
various
modes.
You
can
operate
over
the
top
of
it,
so
it's
not.
G
It
doesn't
fit
the
abstraction
perfectly
it's
good
enough,
but
car
files
it
has
the
basic
algorithm
associated
with
it.
So
considering
pulling
out
that
thing
into
a
separate
library
so
that
you
can,
you
can
just
use
that
if
you
want
to-
and
you
can
write
your
own
abstraction
over
the
top
of
it
and,
however,
you
want
to
interface
with
it
or
maybe
I'll
just
put
keep
it
in
that
library
and
make
it
more
accessible
from
the
outside,
not
sure
yet,
but
that's
going
on.
F
Rod
I
just
I
just
posted
a
link
in
the
chat.
It's
not
something
to
really
bother
with
like
a
lot
right
now,
but
I
want
to
keep
it
in
mind:
it's
it's
a
stage,
three
language
enhancement
to
javascript,
so
it
might
be
usable
within
the
next
three
years
or
so
like
we
might
be
able
to
move
to
it
like
in
a
couple
years,
but
it's
immutable
types
and
they're
god
we're
gonna,
get
a
lot
of
use
out
of
them.
F
They're
they're
phenomenal,
but
the
the
big
thing
is
that
as
you're
working
with
the
block
interface
and
as
we're
designing
some
of
these
other
things,
we
should
keep
in
mind
that
in
a
few
years
we
may
take
a
breaking
change
to
adopt
some
of
these
tools,
in
particular
the
block
api
caches,
both
the
both
the
encoded
and
decoded
state
of
the
block,
and
then
it
basically
returns
you
copies!
F
That's
why
those
unsafe
methods
exist
so
that
you
can
always,
if
you
know
that
you're
not
going
to
mutate
it,
you
can
get
the
raw
one.
But
if
you
mutate
it,
then
you
end
up
with
these
like
awful
awful
bugs
like.
I
did
this
once
in
dagdb
and
it
took
me
like
two
days
to
track
it
down,
and
so
these
are
going
to
be
faster
too.
F
So,
at
some
point
like,
instead
of
having
the
binary
around
it'll,
probably
be
an
immutable
tuple
of
of
the
the
uinta
state.
Basically-
and
you
know,
any
encoded
maps
will
probably
end
up
becoming
records
as
well
and
we'll
also
do
the
copies
out
of
those
so
yeah
I
like
it.
G
Well,
I
think
I
think,
moving
to
an
interface
that
deals
with
a
single
thing
is,
is
the
key
here
and
for
now
it's
the
block,
interface
yep
and
then
in
the
future
that
can
evolve,
but
but
yeah.
The
challenge
we
have
now
is
that
this,
the
data
store
interface,
is
its
string,
key
binary
value
and
yeah.
G
We
have
cids
and
blocks
and
it's
like.
So
this
is
constant
conversion
for
cids
and
it's
just
a
mess.
F
Yeah
yeah,
but
one
thing
to
think
about,
though,
is
that
you
you
can
do
these
deep,
compare
so
they're
immutable,
so
you
can
do
deep
comparisons
against
them,
so
you
can
actually
create
a
set
and
check
if
it's
in
the
set
and
it's
like
a
full
deep
comparison.
So
we
can
even
like
if
we're
encoding,
a
lot
of
data,
and
we
know
that
we
have
a
like
right
now.
F
I
have
a
bunch
of
lrus
of
just
the
block
store,
but
I'm
just
using
those
to
check
if
the
cid
is
in
there
or
not,
we
can
actually
skip
the
encodes
and
decodes
for
common
data
by
checking
if
they've
been
encoded
or
decoded
before.
By
doing
these
new
comparisons
using
the
immutable
types.
So
it's
going
to
be
pretty
cool
once
it's
once
it's
there.
I've
been
asking
for
this
for
like
a
decade
but
yeah,
I'm
pretty
excited
it's
moving
along
the
stages
pretty
quickly
and
the
vendors
are
really
excited
about
implementing
it.
A
Good
to
know
all
right
does
anyone
else
have
any
updates
or
wants
to
share
something
or
as
last
week
I
forgot
to
because
it's
good
to
do
the
beginning
to
ask
for
new
faces
if
they
want
to
introduce
themselves.
B
Hi,
my
name
is
ricardo
malabon.
I
am
from
mexico
and
I
am
very
interested
in
ipsf
as
a
technology,
because
we
have
a
very
challenging
internet
access
in
some
sounds
in
mexico
and
this
technology
that
can
enable
the
centralization
is
very
important
for
us
to
develop.
I
am
not
a
developer,
I
am
an
integrator
or,
as
we
call
here
integrators
and
I
am
very
interested
in
these
kind
of
technologies,
I
am
only
a
guest.
B
A
Thanks
awesome,
cool
yeah
yeah,
so,
yes,
that's
so
do
we
have
any
agenda
items
to
discuss
or
should
we
give
like
35
minutes
to
michael
to
read
about
his
new
stuff.
G
So
I
I
just
on
that
on
the
previous
topic.
I
I
it
ends
with
us
now
now
I'd
like
to
hear
I
didn't
you're
you've
got
a
new
role.
I
think
you're,
you
seem
to
be
doing
a
lot
of
the
go
ipfs
stuff.
Can
you
tell
us
about
where
you
slot
in
now
and
how
we
should
consider
you
in
the
ipfs
team.
H
That
is
the
closest
approximation,
but,
but
honestly,
I
think,
he's
probably
like
stephen-
is
still
around
helping,
especially
some
of
the
transition
stuff.
I
suspect
that
he
will
use
the
opportunity
post
some
of
the
file
coin
stuff
to
figure
out
like
to
do
some
of
the
things
he
initially
wanted
to
do
before
he
got
ipfs
maintainer
sniped.
H
Yeah
yeah
right
so
right,
so
so
that's
sort
of
that
sort
of
stuff.
The
things
on
on
the
to-do
list
and,
like
you
know
so,
some
things
that
are
currently
on
on,
like
my
to-do
list,
are
figuring
out
like
we
have.
We
have
some
like
bit
swap
stuff
around
the
fact
that
we
don't.
H
We
seem
to
have
this
plan
where
we
just
advertise
every
block
in
the
universe
and
like
that's
ridiculous
right
like
if
I
have
a
one
terabyte
zip
file
like
no
one
needs
the
fifth
block
in
the
zip
file
to
be
advertised.
H
They
need
the
first
block,
that's
that's
it,
but
that
requires
some
changes
to
to
bit
swap
and
then
and
then
also
the
dht
I'd
like
to
make
the
dht
more
upgradeable,
basically
make
it
easier
to
sort
of
rotate
and
do
version
bumps.
We
have
this.
Almost
you
know
almost
done.
H
H
There's
actually.
I
would
like
to
may
not
be
as
far
out
as
as
some
may
suspect.
Although
it
may,
I
want
an
ipld
format
for
ips
records
because
I
think
it
would.
H
I
think
it
would
be
useful
in
it
we
needed
to
be
more
more
extensible
and
b.
I
suspect
that
in
a
new
unix
fs
may
come
quickly
in
our
times
they
that
we
will
be
able
to
also
have
mutable
subdirectories.
F
Yeah
yeah,
I
mean
we
should
definitely
do
a
schema
for
ipns
like
to
come
back
to
that
like
we
should
definitely
like
just
write
that
I
mean
we
can
write
that
at
any
time
we
have
the
schema
language.
It's
not
a
very
difficult,
like
kind
of
format
to
work
with
the
mutable
subdirectories
thing
is
interesting
because
I'm
not
sure
how
you
would
want
to
encode
it
like.
Would
you
want
like?
Where
would
you
want
to
put
the
mutability
like?
F
Right,
okay,
yeah
this.
This
is
definitely
a
dimension
of
unix
52
that
we
haven't
explored
yet
so
just
just
a
quick
update
on
on
unix
m62,
because
you
probably
like
haven't
like
been
staring
at
our
specs
repo.
We
we
have.
We
have
a
really
good
data
structure
now
for
all
the
bytes.
F
So
like
a
linear
stream
of
bytes,
we
have
a
data
structure
for
that
that
not
only
like
is
super
efficient
and
nice
and
like
recursive,
and
really
really
awesome,
but
it
doesn't
lock
the
the
layout
of
any
of
this
stuff
down
at
all.
So
it
supports,
like
every
sort
of
like
you
know,
trickle,
dag,
like
flat,
dag
like
all
of
that
stuff.
It
supports
all
of
that.
F
But
you
you
don't
need
any
new
code
to
ever
be
able
to
read
it
or
anything
like
that,
so
we
would
never
have
to
ship
like
new
reader
code.
We
would
just
be
able
to
plug
these
in,
and
so
we
have
that,
as
like,
a
generic
data
structure
called
our
flexible
byte
list,
the
fbl,
because
we
have
other
cases
where
we
want
a
stream
of
bytes
that
aren't
unique
to
us
too,
and
then
in
e62
we're
just
kind
of
pointing
to
that.
We
have
like
a
pr
for
a
draft
specification
of
unixico
c2.
F
It's
somewhat
reasonable.
It
doesn't
include
what
you
just
talked
about,
though,
and
I
think
like
the
more
that
we
look
at
like
that
part
of
the
spec
that
just
like
described
files
and
directories
once
you're
in
ipld
schema
land.
It's
really
easy
to
do
this,
we're
just
going
to
kind
of
argue
about,
like
what
is
the
most
efficient
representation
and
that's
we're
going
to
end
up
arguing
for
months
about
metadata,
like
you
know
like
exactly
how
do
we
encode,
like
dates,
and
things
like
that?
F
So
there's
all
these
like
fiddly
bits
that
are
going
to
take
like
a
long
series
of
bike,
but
the
the
basics
are
all
kind
of
there,
and
I
think
also
for
stuff
like
like
the
the
file
metadata.
It
has
to
all
be
optional
anyway,
because
you,
you
want
to
be
able
to
have
files
that,
like
you
know,
didn't,
have
all
this
unix
success
or
like
traditional
file
system
overhead.
F
H
I
mean
I
files
would
be
reasonable
too.
My
thought
was
more
like.
If
you
get
somebody
made
an
ips
pointer
to
a
thing
that
you
can
use
and
render,
and
then
they
wanted
to
keep
a
collection
of
it
somewhere.
Where
are
they
going
to
put
that
collection
of
stuff?
Oh
they'll,
probably
just
go
and
they'll,
take
it
and
throw
it
in
like
mfs
or
whatever.
H
F
Right,
no,
this
definitely
changed
how
this
definitely
changes.
How
we
were
thinking
about
that
pointer,
because
I
think
the
way
that
we
did
it
was
it's
a
union,
so
it
already
can
be
multiple
things,
but
it's
either
like
the
inlined
version
or
it's
the
link.
I
think
it's
a
kind
of
union
on
that
or
maybe
might
have
been
before.
I
actually
had
good
kind
of
union,
so
it
might
not
be,
but
it
should
be.
F
H
F
This
is
the
way
that
this
this
is
the
way
that
we've
been
looking
at
it
is
that,
like
cid,
is
a
low-level
primitive
standard
like
like
kind
of
multi-formats
right.
That's
like
the
immutable
pointer
part,
all
across
kind
of
like
our
our
data
structures.
We
take
like
these
primitives,
like
the
cid
or
like
bytes,
and
then
we
create
like
a
bigger
layout.
That's
like
here's.
F
What's
like
you
treat
this
like
bytes
like
everywhere,
but
actually
it's
like
a
series
of
fights
and
the
way
that
we're
thinking
about
this
is
like
okay,
we
we
have
links.
How
do
we
create
like
a
more
complicated
link
that
has
other
things
it's
like?
Does
it
have
a
path
in
it?
Does
it
have
like
you
know?
Does
it
have
an
ips
record
associated
with
it
so
yeah?
F
I
think
we
even
had
like
a
small
discussion
about
mutable
links
and
and
what
that
kind
of
data
structure
could
look
like,
but
yeah,
I
think
that's,
that's.
I
think
you're
right,
that's
probably
the
right
way
to
attack
it.
It's
like
how
do
we
talk
about
links
that
that
have
ips
records
associated
with
them
so
like
it
points
to
the
immutable
state
like
that's
in
there,
but
it
also
has
a
has
an
indication
of
like
how
you
might
update
that
yeah.
Okay,
okay,
interesting
yeah.
E
I
have
two
large
groups
of
observations.
One
is
a
bunch
of
this
turns
into
application
level,
semantics
anytime,
you're
getting
around
mutability,
and
so
what
I
want
to
be
able
to
do
is
make
a
schema
for
unix
of
sp2
that
describes
all
of
the
immutable
parts
and
then
stops
and
then
hopefully
we're
going
to
be
able
to
reuse
this
as
some
sort
of
a
library
like
we
use
this
compu
compositionally
to
produce
a
mutable
file
system,
a
space,
mutable
file
system
method
and
in
slightly
more
detail.
E
I
had
a
big
number
too.
No
idea
what
it
was
brains
are
hard.
F
Well,
like
I
don't
know,
I
don't
know,
though,
like
the
thing
about
this
is
that
even
when
you
have
the
mutable
pointer,
you
also
have
the
immutable
one.
So
it
might
be,
it
might
be
worth
it
to
just
make
it
one
spec
since
you,
it
is
always
immutable
and
the
application
tier
can
always
just
say.
Like
I'm
going
to
ignore
the
mutability
right,
I
mean
it
does.
F
F
I
should
unwind
my
thinking
a
little
bit
here.
I
don't
see
a
difference
between
the
mutable
and
the
immutable
standard,
because
you're
always
only
looking
at
the
immutable
state.
If,
if
it's
a
mutable
pointer,
then
the
update
operation
is
to
mutate,
the
graph
and
then
read
the
new
immutable
state.
F
So
it's
not
as
if
these
are
actually
like
two
different
things
and
if
you
don't
have
a
mechanism
by
which
you
can
update
the
mutable
state,
you're,
just
always
reading
the
immutable
side
anyway,
it's
the
same.
It's
like
the
same
thing
right
like
the
immutable
version,
doesn't
need
any
of
the
code
for
the
mutability
and
there's
no
conflict
like
can.
I
can
you
name
a
space
where
you
actually
like,
where
it
would
prohibit
like
where
it
would
actually
be
a
problem
that
somebody
put
the
mutability
in
there.
E
Which
is
one
of
the
things
I
wanted
to
mention
real,
quick
about
the
link
interface
and
the
specific
question
you
asked
about
that
earlier.
Can
we
make
ipns
fit
into
the
link
interface,
especially
if
you're
talking
about
the
go
ipod,
prime
definition
of
it?
The
answer
is
hard:
no,
because
yeah,
yeah,
okay,
yeah.
F
Yeah
yeah,
I
like
like
that
that's
my
point
right
is
that,
like,
if
you're
looking
at
it
like
a
mutable
pointer,
is
just
an
immutable
pointer
that
tells
you
how
to
mutate
the
graph
to
get
the
new
state.
It's
not
actually
a
mutable
pointer
like
an
application.
I'll
put
it
this
way
in
application,
even
one
that
is
online
and
has
the
capability
of
updating
the
mutable
state.
It
should
never
read
the
graph
as
if
it's
mutable
it
should
never
like
go
and
just
like
proactively
look
at
that.
It
should
always
just
go.
F
G
It's
it's
like
it's.
It's
a
breakpoint
like
adls
are
conceptualized
to
be
where
you
get
to
a
thing
and
you
jump
out
of
it
into
some
other
space,
not
like
a
link
which
is
an
integrated
part
of
the
graph.
It's
a
I
get
here.
I
get
to
make
a
choice
that
is
in
codeland
somewhere
else,
not
in
the
state
of
the
data.
F
Yeah
and
and
the
immutable
graph
can
only
be
read
right,
like
by
definition,
there's
no
write
operations,
so
it
it
like
an
immutable
version
of
unix.
Of
this
youtube
is
the
same
thing
you're
just
only
reading,
through
the
the
immutable
side
of
it
and
you're.
Never
thinking
about
the
mutation
operations
right.
C
C
Right
right,
but
all
of
this
is
an
implementation
detail
that
is
specific
to
how
your
app
deals
with
producing
this
static,
immutable,
dag
something
else
that
reads
or
writes
such
as
that
will
not
obey
any
of
this
interface
or
implement
them.
It
will
do
things
differently,
but
that's
true
of
all
adls
right
now.
E
C
It
doesn't
work
this
way
right.
So
basically,
basically,
what
I'm
trying
to
understand
is
a
number
of
you
throw
mutability
as
a
concept
liberally
around,
and
it
doesn't
click
for
me
like.
Where
does
it
actually
fit
into
what
we're
doing
with
content
and
traceability,
because
they
just
don't
click.
F
Yeah
I
mean
in
this
case
a
mutable
pointer
is
an
immutable
pointer
with
a
hint
as
to
how
you
might
update
to
a
new
state
of
this
graph,
but
that
mutation
operation
is
entirely
in
the
application
here.
Right.
F
I'll
give
you
a
better
example
that,
like
you've
been
involved
in
so
the
unix
this
file.
Permissions
like
these
are
not
a
real
thing
in
ipfs
right
like
we,
we
don't
have
those
user
records
and
user
ids.
We
have
no
idea
what
that
means.
It
like
literally
means
nothing
and
we
guarantee
no
security
around
it,
because
it's
just
meta
data
that
we
wanted
to
like
hold
on
to
from
the
file
system
that
we
took
the
data
from
and
so
like.
C
G
I
think
I
think
a
better
analogy
for
this
might
be
if
you
were
to
take
a
a
set
of
files
and
directories
from
mac
os
and
put
on
linux.
G
There
would
be
a
bunch
of
leftovers
that
would
just
that
you
wouldn't
see
on
mac
os,
like
things
like
you
know
the
cached
icons
and
some
other
metadata
that
just
don't
appear
like,
because
the
because
mac
os
interprets
them
in
a
special
way,
whereas
on
on
linux,
it
doesn't
so
so,
if
you
so,
if
we
had
some
kind
of
special
pointer
type,
it
may
be
for
some
implementations.
It
would
just
show
up
as
some
weird
little
file
or
a
marker.
G
That
is
just
a
dead
end,
whereas
if
you
interpret
interpret
it
through
the
lens
of
this,
the
pointer
adl,
maybe
then
it
becomes
something
a
magical
portal
to
a
mystery
land.
I
F
I
mean
that's,
that's
all
that
it
really
is.
That's
just
why
I
think
that,
like
it's,
not
it's
not
two
specs,
it's
it's
just
one
stack.
E
E
E
F
Yeah
yeah,
no!
No,
I
should
have
put
that.
That's
how
we
should
do
it.
I
think
that's
how,
like
that's
a
good
practice
that
we
should
have
that
we
should
always
encode
the
immutable
state
and
the
hint
to
mutated
back
again
but
yeah.
I
think
that
people
do
this
already
with
ips
right,
like
they
just
put
an
ips
record
somewhere
and
they
don't
say
like
like
they're
like
go.
Look
this
up
right,
like
that's
what
they're
saying
with
it:
they're,
not
like
also
linking
to
the
immutable
state
outside
of
that.
F
E
F
F
If
you
can
avoid
it
only
point
to
like
some
mutable
pointer,
because
then
you
lose
all
of
the
cash
ability
right.
F
So
if
you
can,
you
always
do
both
but
like
if
you're
coming
from
anywhere,
that
is
not
ipld
and
content
disability,
then
your
instinct
is
to
think
of
a
link
as
a
mutable
thing,
that
people
always
go
and
look
up,
and
so
it's
like
going
to
be
people's
instincts
to
actually
do
what
we
think
in
most
cases
is
the
wrong
thing
and
we
should
drive
them
away
from
it,
but
yeah
you're
right,
like
there's.
There
are
many
interpretations
to
get
into
of
these
things.
Yeah.
H
F
That's
a
really
good
question.
I
think.
E
H
The
reason
I
ask
is
that
if
you
were
to
do
anything
with
ipns
stuff,
you
may
want
to
know
the
cid,
not
just
the
data,
not
just
the
record
right,
because
the
there's
the
cid
and
there's
the
record.
But
if
the
key
information
only
lives
in
the
cid
and
not
in
the
record,
because
you
were
trying
to
save
bytes.
F
Yeah
yeah
yeah;
no!
No!
That's!
That's!
Probably
fine,
especially
when
it's
that
shallow
okay,
when
it's
that
out
shallow
yeah.
F
This
is
actually
like
a
something
that
we've
been
contending
with
a
little
bit
where
some
of
our
interfaces
did
not
think
enough
about
how
state
gets
carried
over
as
you
traverse
and
how
a
lot
of
data
structures
actually
like
aren't
interpretable
without
the
state
that
you
carried
over
and
that
gets
a
little
tricky
with
some
of
the
interfaces
but
like
at
this
point,
I'm
pretty
comfortable
saying
that,
like
most
data
structures
that
are
sufficiently
complex
have
to
do
it,
I
could
do
it
in
dagdb.
F
I
think
unix
fest
probably
doesn't,
though
I
think
like
you
it's
designed,
so
that
you
can
take
any
part
of
it
and
that's
like
fine
to
attach
to
another
graph.
So
we're
we're
designing
for
that
in
that
case,
so
it
should
be
fine,
but
there
are
so
like
I
mean
look
at
the
file
coin
chain.
You
know
look
at
like
any
database.
You
know
you're
you're,
don't
look
at
the
falcon.
C
F
H
Yeah,
I
would
also
so
this
is.
This
is
like
thank
you
all
for
letting
me
snipe
you
for
a
while
with
that
would
also
like
I,
you
know,
ideally
depending
on
how
our
times
line
up,
either
towards
the
end
of
this
year
or
next
year,
to
actually
get
all
of
the
cool
stuff
that
eric
has
been
working
on
for
a
while
to
like
live
and
go.
H
Ipfs
is
more
as
more
than
like
a
it's,
also
kind
of
maybe
here
as
a
graph
sync
thing,
especially
just
having
recently
like
I
added
like
an
ipfs,
dag
stat
command.
That
was
really
simple
just
because,
like
people
were
like,
oh,
how
do
I
get
you
know
like
penning
services
were
like?
H
Oh,
I
need
to
get
the
size
of
an
object
and
then
they
were
using
like
the
the
object
stat,
which
is
like
no
right
right
for,
like
various
reasons
is
like
no,
and
also
it
was
preventing
some
of
these
some
of
the
pinning
services
from
storing
arbitrary
ipld
data,
because
they
had
no
way
of
figuring
out
how
much
to
charge
people
because
they
didn't
have
any
idea
of
how
much
data
it
was
taking
up
right.
So
they
were
like
oh
you're,
not
you're,
not
tag
pb
bye.
H
All
right
are
you
gonna,
so
yeah
yeah?
No,
it.
C
Was
the
very
same
conversation
that
we
kind
of
started
like
two
months
ago,
I
believe,
with
with
matt
and
did
basically.
H
Right
so
there's
like
various
reasons
but
but
but
like
in
general,
making
these
things
like
surfacing
them
more
high
level.
I
think
it
will
also
help
with
ipfs
is,
in
my
opinion,
a
little
too
more
a
little
too
binary
right
now
and
a
little
less
library,
especially
on
the
go
side.
H
Javascript
does
a
better
job
at
library
things
we
go
side
leaves
to
be
desired,
but
I
suspect
that,
especially
if
you
start
getting
ipfs's
library
things,
people
are
going
to
want
to
start
interacting
with
all
the
ipld
things,
because
I
think-
and
I
was
having
a
talk
with
with
dietrich
when
we
were
we
were
talking
to
some
folks
who
were
like
microsoft
is
working
on,
is
working
on
ion
and
it's
like.
Inevitably,
all
of
these
conversations
end
up
being
like.
H
D
H
F
Yeah
yeah,
I
think
the
early
feedback
that
we
had
gotten
was
like,
if
you
want
to
build
new
data
structures,
really
one
in
some
kind
of
code
gen.
So
that's
like
where
we've
been
spending
the
time
but
like
the
dag
api
and
all
of
that
stuff
in
ipfs,
really
should
be
able
to
move
like
as
soon
as
you
want
and
then
unix
just
v2.
F
E
Yeah,
the
checklist
for
features
internally
is
probably
at
like
70
or
80,
and
the
things
that
are
remaining
are
the
less
used
things,
but
turning
it
into
a
cli
facing
tool
and
doing
some
of
the
polish
to
make
it
like
usable
by
anyone
other
than.
Unfortunately,
roughly
me
is
still
a
big
to-do,
so
I
don't
have
a
commercial
on
that
one
as
well,
but
it's
getting
a
lot
closer
soon.
H
Yeah,
no,
I
I
don't
suspect
any
of
these
things
are
like
none
of
these
are
like
happening
tomorrow,
but
they're
like
oh
they're,
they're
on
the
radar
of
of
things
that
you
know
we're
neglected
for
a
little
while
because
it
was
like.
Oh
I
lit
peter
p
is
all
the
fires.
So
let's
go
do
all
the
lipid
few
things
and
then
it's
like
all
right
cool.
Let's
go!
Do
the
ipld
things.
A
All
right,
all
right,
michael,
do
you
want
to
talk
the
last
five.
F
F
Yeah
yeah,
I
I'm
putting
together
some
slides
for
all
hands
and
stuff,
so
I
should
like.
All
of
this
should
be
a
lot
better
pretty
soon.
The
readme
is
a
lot
better
than
it
used
to
be.
The
spec
is
a
lot
better
than
it
used
to
be
so
if
you're
interested
in
z,
I
would
sorry
I
got
a
call
and
ios
thinks
that
no
matter
what
is
happening,
you
have
to
take
the
call.
F
F
It
is
a
very
new
way
to
look
actually,
no
here's
what
I'll
say
and
I've
told
a
few
people
this
today
already,
but
don't
we,
you
can't
look
at
it
like
traditional
compression,
because
the
relationship
of
a
compressor
to
the
person
generating
the
data
is
so
different.
F
So,
like
a
string,
compressor
takes
anybody's
string
data
right,
a
video
compressor
takes
anybody's
video
data
and
when
you're,
making
a
video
like
the
the
cinematographer
isn't
like
writing
out
like
what
the
h.264
compression
rate
is
and
then
adjusting
their
shots
like
that's,
not
how
video
is
made.
It's
too
con,
like
one.
The
compressive
logic
is
too
complicated
to
get
your
head
around
and
two
like.
F
That's
just
not
the
relationship,
but
data
structures
are
very
different
like
if
we're
gonna,
compress
a
data
structure,
the
the
person
producing
it
isn't
can
be
an
active
participant.
So
it's
not
just
like.
Oh,
here's
a
bunch
of
techniques
to
really
get
down
the
size
and
the
representation.
It's
also
like.
F
How
do
we
describe
these
features
to
people
so
that
they
can
adjust
their
data
structure
to
match,
because
we
do
this
by
hand
right
now
in
seaboard
like
we,
we
sit
there
and
we
talk
about
every
bite
that
seborrhe
uses
to
represent
a
structure
so
that
we
can
get
it
down
to
the
minimal
amount
of
bites.
If
we
had
really
simple
compression
techniques
that
could
shave
those
even
farther,
then
we
would
definitely
chop
things
down
even
more,
not
to
say
that
it
doesn't
work
over
generic
data.
B
C
Really,
I
think
what
is
what
needs
to
be
called
out
is
what
you
are
working
on
is
our
container
format
for
data
model,
and
you
know,
and
and
and
the
like,
is
generally
relatively
fat
itself,
so
you
focused
on
compressing
the
container
format
and
the
raw
raw
payload
is
kind
of
still
left
the
way
it
is
for
the
most
part,
if
it's
binary,
and
for
that
there
are
already
like
you
know,
generic
compression
techniques-
and
you
even
wrote
about
trying
to
do
deflate
and
stuff
like
that-
is
that
you
focus
strictly
on
the
container
metadata
which,
because
of
how
we
do
things,
there
are
gains
to
be
made
there,
knowing
how
we
do
things.
F
Yeah,
the
language
that
I
landed
on
with
the
research
team
is
structural
compression,
so
we're
compressing
the
structural
representation
of
the
data,
we're
not
actually
touching
the
value
data,
which
is,
which
also
makes
it
very
different
than
other
compression
schemes,
because
you
can
do
double
compression
on
it.
Right,
like
that's,
that's,
usually
like
a
big
no-no,
but
like
we,
we
put
all
of
that
data
that
could
be
compressed
into
the
string
compressor
like
over
here,
and
you
can
still
use
a
string
compressor
on
it.