►
Description
Meeting notes: https://github.com/ipfs/team-mgmt/issues/992#issuecomment-657646967
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
A
Hello:
everyone
welcome
to
the
ipfs
core
implementations
weekly
sync
for
Monday,
the
13th
of
July
2020
I
am
making
brain
I
will
be
your
host,
we're
going
to
go
through
the
high
priority
initiatives
and
the
other
industries
everyone's
working
on
and
give
some
updates.
So
I
purchased
is
number.
One
upcoming
in
ship
releases
took
a
little
bit
about
Jess
ipfs,
it's
gonna
be
released,
come
here
nice
tomorrow
there
were
some
bugs.
There
was
a
memory
leak
that
we
got
a
fix
in
floor
thanks
to
Jacob,
so
I
wanted
to
kind
of
wait.
C
C
The
link
to
the
issue
is
in
the
notes
asked
here
is
for
anyone
interested
in
generic
cleaning
service
services
API
to
review
the
specs
I,
also
linked
human
readable
version.
We
have
open
API,
spec
and
human
readable
version
of
that.
The
plan
is
to
finalize
the
spec
within
like
before
the
end
of
this
week.
Hopefully
in
next
week
two
days
and
then
we
will
ask
core
implementations.
C
Working
group
I
prefers
GUI
working
group
and
Vario
spinning
services
and
Falcon
partners
who
are
interested
in
implementing
something
like
this
to
give
a
sign-off
or
to
give
last-minute
suggestions
and
changes,
but
long
story
short.
We
want
to
close
this
freeze
it
this
week
and
agree
on
a
version
that
can
be
implemented.
We
made
tweak
small
things
as
we
go,
of
course,
when
people
implement
stuff
and
figure
out.
C
D
D
Yeah,
so
the
subdomains
support
for
Edie
keys
is
done
that
got
merged
on
Friday
I,
think
woohoo,
the
we
need
to
finish
up
an
additional
initialization
work
for
ipfs
in
it
with
Edie
keys.
That
is
I
believe
blocks
on
me,
fixing
the
thing
in
jaya
slippy
to
pee,
so
that
I
penis
does
not
break
for
Jas.
When
we
we
launched
that
so
I'll
be
I'll,
be
getting
back
to
that
this
week
there
were
a
few
bugs
that
popped
up
last
week
on
that
needed
to
tend
to,
but
I'll
get
back
to
that
this
week.
D
Key
rotation
is
ready,
but
that's
blocked
on
getting
that
done
as
well,
just
so
that
we
can
have.
If
we
need
to.
We
want
to
roll
out
a
key
rotation
early.
We
could
do
that
with
just
RS
a
default
support,
but
right
now
we
would
like
to
get
in
edie
default
support
for
that
before
pulling
that
done,
and
then
IP
vestige
n
list
also
now
supports
output
for
base
36
+,
CI
D,
we
won
I,
think
stupid
I
know.
Is
there
any
other
things
they're,
adding
that
I
didn't
cover.
B
E
No,
that's
fine.
We
can
wait.
I.
Think
probably
the
smartest
way
to
do
this
actually
is
to
take
the
key
rotation
and
the
initialization
stuff
and
merge
all
of
those,
but
have
the
default
set
to
RSA
and
then
have
another
PR,
which
is
the
change
all
the
defaults
PR,
which
just
changes
all
the
defaults
to
elliptic
curves
and
also
does
things
like
changes,
the
IP,
NS
outputs
to
base
36
by
defaults
and
whatever.
B
E
B
C
C
This
version
is
very
simple:
if
you're,
if
your
CID
is
too
long,
we
try
to
convert
it
to
represent
it
in
base
46.
If
it
does
not
help,
we
return
an
error.
That's
sorry!
This
is
the
long
for
DNS
spec.
You
can
still
load
it
from
path
based
gateway.
However,
for
subdomains
we
just
return
rather
an
error
which,
on
to
any
magical
conversion,
yeah,
that's
it
that
with
merged
and
the
second
one
is
contributed,
I
believe
by
Michael
Moore
from
if
rah
it's
cool
PR,
which
add
supports
to
a
sibling
header
X
forwarded
host.
C
C
You
may
have
different
uses
for
this
header,
but
the
probably
the
most
common
one
is
when
you
want
to
enable
subdomain
support
on
existing
gateway,
but
you
want
to
redirect
it
to
a
different
host
name
to
keep
origin
isolation
and
like
redirect
to
a
new
subdomain
on
a
different
base.
Domain
yep
check
the
PR
for
details,
but
that's
it.
There
are
also
dogs,
updated
yeah.
That's
it.
F
F
I
basically
need
to
get
some
clean-up
on
this
and
also
add
more
tests,
and
it's
not
totally
covered
yet
and
after
that
also
just
integrating
the
SNP
records
to
exchange
off
the
others
and
for
the
next
initiative
the
st.
Pierre
records
in
the
gossips,
a
1.1
design,
be
attackers
I'm
still
blocked
on
reviews,
so
mostly
no
progress
since
last
week
and
the
gossips
urban
Cayman
was
also
not
working
on
this
last
week.
So,
basically
also
not
any
development
progress
and
that's
it.
A
A
H
Since
last
week,
I
got
a
review
feedback
said
I'll
be
acting
on
dog
PB
changes
said
finally
got
merged
and
released,
but
that
was
a
major
really
so
I'll
have
to
propagate
those
across
all
the
other.
Libraries
like
UNIX
of
s
and
I,
suppose,
there's
more
once
that
is
done.
I
think
it
should
be
ready
for
another
review
cycle.
H
The
next
one
is
also
mine,
which
is
improving
web
while
ad.
Currently
there
is
a
jest
ipfs
to
request
in
review,
we
had
a
call
last
week
and
made
a
decision
about
going
with
a
custom
form
data
implementations
that
use
blobs
under
the
hood.
We
may
reconsider
the
decision
later
on
in
favor
of
using
for
native
form
data,
because
it
turns
out
metadata.
Support
is
only
implement
just
like
FS,
so
maybe
changing
it
now
won't
be
too
bad
or
there'll
be
no
better
time
to
do
that.
H
Writing
some
more
tests
to
kind
of
catch
regressions
and
my
rice,
because
their
long
process
of
normalization
happening
that
car
tests
would
not
catch.
I
also
spent
some
time
trying
to
see
if
we
can
use
fetch
blog
as
Hugo's
suggested
last
week,
our
goal
there
are
some
issues
with
fetch,
blob
and
I
start
working
with
a
flashbulb
fetch
globe
project
to
try
to
see
if
we
can
address
those
in,
but
I
think
some
of
those
could
be
just
ignored
for
now.
H
A
I
H
But
I
I
all
go
somewhere
quickly,
and
maybe
we
can
do
that
up
sure.
So
one
thing
that
I
brought
up
can
we
consider
something
like
RFC
process
may
be
inspired
by
rust.
It
really
works
well
in
rust
project.
H
C
C
I
I
so
I
I
do
like
rusts
are
a
few
process.
I
think
that
it's
sort
of
impossible
to
go
from
no
process
to
in
RFC
process,
like
you,
you
to
take
like
some
steps
before
that,
like
documenting
some
governance
and
how
decisions
get
made
would
be
like
a
logical
kind
of
first
step.
I,
don't
think
that's
documented
anywhere.
We
we
did
something
like
that.
Just
for
I
feel
these
specifications,
because
all
the
libraries
are
pretty
much
single
maintainer.
So
we
don't
have
like
a.
H
I
I
would
say
that,
like
at
this
stage,
the
most
important
thing
is
that
there's
something
that
makes
people
formalize
their
objections.
So
you
can
comment
and
have
an
opinion,
but
like
a
formal
objection,
is
something
that
you
say
like
much
clearer
and
when
you're
asking
like
hey.
Are
there
any
more
objections
at
this
point,
like
objections
need
to
be
very
clearly
stated,
like
no
I,
don't
think
that
that
should
go
in
for
this
reason,
so
that
people
have
something
actionable,
they
can
do
to
potentially
change
your
mind
and
and
it
just
Alinea.
I
H
H
Do
that
thank
you
and
I
had
other
items
that
it's
kind
of
big,
larger
discussion.
So
the
question
is:
should
we
consider
a
network
IP
LD
is
another
breakout
project
from
ipfs
and
the
reason
I'm
bringing
it
up.
I've
been
talking
to
a
lot
of
our
permanent
users
in
terms
of
trying
to
figure
out
what
the
IP
and
browser
should
be
as
a
minimal
API,
and
it's
clear
that
everyone
is
essentially
using
that
sort
of
IPL,
devious
persistence
with
a
few
bits
and
pieces
of
exception
here
and
there.
H
So
and
these
kind
of
ideas
that
had
been
brewing
in
my
head.
It
clear
that
at
some
point
likely
to
be
was
identified
as
a
separate
thing
that
is
useful
on
its
own
and
then
same
thing
happened
with
a
IP
LD
itself,
but
it's
just
data
layer.
Is
there
I
think?
Maybe
it's
a
time
to
consider
what
another
breakout
could
be?
Is
that
is
IPL,
Davis
persistence
and
ipfs
network
baking
it
and
then
ideas
could
be
sink
on
top
and
people
who
don't
care
about
the
file
system
piece
itself.
H
E
My
brief
two
seconds
on
that
is
that
it's
not,
but
whatever.
Maybe
it's
just
like
a
naming
thing
but
like
I'm
here
fuss
is,
is
basically
that
it's
just
that
the
ipfs
does
and
jazz
type
of
us
do
way
more.
Things
then,
are
strictly
required
by
ipfs,
and
so
we
should
have
libraries
and
we
should
have
applications
and
the
applications
should
not
be
a
name.
The
same
thing
is
the
library
make.
E
H
I
It
is
this
sort
of
network
piece
potentially
and
then
we're
doing
a
lot
of
experiments.
On
top
of
that,
which
is
you
know
what
you
get
when
you
install
go
ipfs
and
JSI
DFS,
you
get
all
of
this
extra
stuff
that
we've
been
working
on,
that
we're
really
interested,
but
that
differentiation
is
it's
yeah
really
hard
and
very
confusing.
I.
Think.
E
H
So,
on
my
end,
one
thing
that
has
been
sort
of
why
I
bring
this
up
as
we
try
to
embark
into
sharing
node
sync
across
browser
tabs
right
now.
It
is
actually
very
helpful
to
have
something
that
is
minimal
and
that
is
not
full-blown
ipfs,
so
idea
is
to
be
driven
by
the
users
demand
sorta
and
clearly
it
is
been
identified
that
this
is
more
or
less
what
it
is
given.
Also
a
new
I
kill.
H
This
talk
that
is
coming
in
I
think
it
becomes
more
and
more
clear
that
there's
just
I
what
people
are
using,
essentially
I,
kill
D,
and
then
they
just
want
to
be
stored
and
to
be
able
to
retrieve
which
is
much
lesser
school,
and
we
can
also
eat
rate
on
that
without
having
to
break
anything
either
for
application
users
or
current
GSI
PFS
users,
and
also
can
just
resync
what
would
make
sense
for
that
specific
use
case.
Not
all
the
other
use
cases
I
mean.
I
I
wouldn't
underestimate
how
many
people
are
not
thinking
of
it
and
using
it.
Only
in
that
scope,
I
mean
like
that.
That
might
sound
attractive
to
me
being
that,
like
I,
run,
I
killed
B
and
that's
like
a
very
ideal
date,
centric
way
of
looking
at
it,
but
I
think
that
actually,
like
a
lot
of
people
using
IP,
FS
right
now
think
of
it
as
like,
more
of
an
API
rather
than
a
protocol
and
there's
a
lot
of
API
surfaced.
I
Therefore,
the
things
that
they
do
and
files
is
like
a
very
important
part
of
that,
and
then
the
network
is
like
probably
the
most
important
part
of
that
and
by
the
network.
I
also
mean
the
persistence
layer,
yes,
and
so,
like
those
things
are
like
super
super
important
to
them,
and
it's
it's
a
little
bit
more
difficult
than
I.
Think
that
we're
giving
it
credit
for
to
like
trim
down
the
API,
for
instance,
because
that
would
be
like
a
necessary
part
of
of
this
change.
I
think
yeah.
D
Like
time
here,
we're
couple
minutes
over
and
well
I
think
this
is
a
worthwhile
conversation
I.
Think,
realistically
we're
not
going
to
be
able
to
touch
this
until
q4,
so
I,
every
kind
of
punt
that
but
at
least
we
can,
we
can
have
the
ongoing
conversation.
I
think
in
the
notes,
but
realistically,
like
nothing's
gonna
happen
for
at
least
until
q4.
A
I
I
Think
that's
like,
for
instance,
like
a
good
example,
is
actually
the
block
API
where
we
we
wrote.
I
wrote
that,
like
a
year
ago
and
we've
been,
you
know,
putting
a
lot
of
our
stuff
on
it
ever
since.
But
you
know
every
three
months
we've
sort
of
figured
out
like
there's
another
breaking
change,
that's
gonna
have
to
happen
to
make
things
actually
work,
the
way
that
they
need
to,
and
so
it's
never.
You
know
we
because
we
keep
seeing
these
we're
not
going
to
have
you
take
it
until
we're
done
with
these
breaking
changes.
I
You
take
one
breaking
change
rather
than
seven.
The
dance
multi-format
stuff
is
similar
and
in
some
ways,
kind
of
bigger,
in
that
it's
not
only
JavaScript.
It's
actually
multi
formats
as
a
standard
and
a
specification
is
not
changing,
but
the
way
that
we've
interpreted
that
into
language
librarians
across
the
board
has
been
like.
We
have.
We
have
like
taken
the
wrong
approach
to
multi
floor
mats
and
now
the
multi
floor
mats
table
has
grown
and
the
number
of
hashing
functions
and
codecs
has
grown.
It's
very
very
obvious.
I
These
are
much
more
obvious
in
JavaScript
as
a
problem
in
other
languages,
because
you're
confronted
with
how
much
code
that
you
ship
a
lot
more.
Obviously
when
you
ship
the
bundle
but
in
JavaScript,
even
the
size
of
the
table,
is
a
problem
like
it's
noticeable
in
the
bundle
size
that
there's
this
big
multi
formats
table
in
there.
I
Like
you
know,
we
look
at
the
charts
of
like
where
the
block
API
is,
is
spending
a
lot
of
its
its
its
budget
on
on
this
and
like
the
tables
not
insignificant,
and
it's
only
growing
and
we
even
started
to
get
pushback
on
adding
things
to
the
multi
floor
mats
table
because
the
table
was
so
big
and
people
are
loading
into
the
code.
So
this
is
this
was
the
wrong
way
to
do
things
right.
I
So
the
way
that
we're
looking
at
multi
formats
going
forward
in
all
languages
is
that
multi
floor
mats
is
like
an
interface
that
you
load
up
with
the
implementations.
The
table,
information
that
you
care
about
and
the
representations
that
you
get
from
multi
formats
are
somewhat
agnostic
of
needing
to
have
that
table
information.
So
you
can
parse
a
multi
hash
and
know
what
that
integer
is.
Even
if
you
don't
have
the
hashing
function-
and
you
would
know
this
bubbles
up
like
really
as
far
as
a
CID
right,
so
CID
has
properties
for
the
string
codec.
I
That
is
a
problem
like
we
actually
have
to
break
that,
because
we
have
to
be
able
to
represent,
see
IDs
to
things
that
we
don't
have
a
codex
or-
and
you
can't
represent
the
string
unless
you
have
the
table
information.
So
what
we've
been
doing
is
like
figuring
out
the
interface
that
looks
the
nicest
that
we
think
is
the
right
way
to
kind
of
load,
this
information
up
and
then
sort
of
bubbling
it
up
the
stack
and
updating
the
block
interface
now
and
so
for
most
consumers.
This
won't
look
that
different
like
right.
I
Now
you
serve
like
the
old
block
interface.
For,
ideally,
you
would
like
import
the
block
and
the
block
would
come
with
a
bunch
of
codecs
and
now,
if
you
import
block
/
defaults,
you'll
get
the
block
with
a
bunch
of
codecs
a
bunch
of
hashing
functions.
Ipfs
will
probably
just
have
its
own
block
somewhere
and
you'll
import
that
block
and
it'll
have
all
the
codecs
and
hashing
functions
and
base
encoders
did
IPF
a
secure
spot.
I
You
can't
just
import
it
necessarily
because
you
may
need
to
configure
it
or
you
may
need
to
allow
the
user
to
configure
it
with
more
codecs
or
more
hashing
functions
or
something.
That's
gonna
be
like
a
pretty
substantial
kind
of
code
change
like
architectural
II,
it's
going
to
change
a
lot
of
code
paths,
since
we
know
that
this
is
such
a
huge
break,
we're
taking
all
of
the
other
breaking
changes
that
we've
been
putting
off
for
a
long
time,
so
there's
other
stuff
in
this
refactor.
I
That
is
not
strictly
this
multi
formats,
refactor
we're
getting
rid
of
buffer
and
doing
everything
as
you
into
eight
array.
That's
a
really
big
change.
We
you
know
that
the
CIB
change
is
also
really
big,
because
it's
without
you
type,
we
were
moving
the
ESM
because
we
don't
want
to
also
migrate
to
ESM
in
six
months
to
a
year.
This
is
just
like
stuff
that
it's
easier
to
take
now
and
deal
with
it
than
it
is
to
suffer
more
braking
changes
in
the
future.
I
I
All
over
the
place
you've
got
cid
that
is
see,
I
decode
all
over
the
place,
and
we've
had
to
think
really
hard
about
what
the
failure
cases
should
look
like,
so
that
it's
really
easy
to
see
where
you
need
to
update
rather
than
having
bugs
appear
transparently,
and
you
just
do
the
wrong
handling,
but
not
see
an
exception.
So
there's
a
million
notes
on
that
and
different
threads
that
we
can
go
over
once
it's
time
to
upgrade
but
yeah.
I
If
you
like
to
get
on
your
radar
that,
like
there
is
a
pretty
big
breaking
change
coming,
but
it's
not
coming
through
us
ipfs
anytime
soon,
but
you
know
it's.
It's
always
been
up
to
you
when
you
want
to
upgrade,
but
we're
not
even
recommending
that
you
upgrade
within
the
next
like
three
or
four
months
like
we're.
It's
not
ready
yet,
and
we
actually
have
other
priorities
this
quarter.
So
we're
not
gonna
be
able
to
finish
it
right
now.
So.
H
I
So
hopefully,
hopefully
most
of
that
has
worked
out
as
we
update
our
stack
to
it
and
as
people
like
GSI
BFS,
light
to
it
like.
Hopefully,
we
shake
out
most
of
those
issues
in
that
process.
If
there's
any
remaining,
though,
like
we're
still
open
to
taking
a
breaking
change,
you
know
in
the
process
of
you
upgrading
if
it
makes
that
upgrade,
you
know
easier
and
more
reasonable
and
it's
a
change
that
we
need
to
take
through
that
at
more
fundamental
level.
I
H
Yeah,
maybe
let
me
rephrase
it
is
differently,
so
one
of
the
things
that
I've
been
trying
to
are
wanting
to
do
is
for
the
shared
ipfs
known
in
browser
to
try
to
take
the
new
IP
all
this
stuff,
and
we
only
have
a
block
API
and
expose
those
and
kind
of
have
that
as
a
replacement
for
the
tag
API.
So
we
can
actually
learn
about
those
things
that
may
be
incompatible
or
problematic
earlier
on,
given.
A
H
I
Depends
on
how
isolated
that
code
is.
So
if
that
code
is
really
isolated
and
it's
not
super
integrated
and
the
rest
of
the
stack,
it
may
be
a
good
time
to
take
it
earlier,
because
it
would
one
give
you
experience
with
it
and
you
would
be
able
to
flush
out
any
issues
early
on
and
to
for
something
like
this
worker
interface.
I
Some
of
these
breaking
changes
are
probably
going
to
make
your
life
a
bit
easier
right
like
having
you
into
a
de
Rais
everywhere,
would
probably
make
it
life
easier
than
having
to
deal
with
the
buffer
polyfill.
So
it
may
be
worth
it.
I
mean
I'm,
not
I'm,
not
in
your
code.
So
I
can't
like
make
the
recommendation
for
you,
but
it
may
be
something
to
think
about.
Another
thing
I
should
mention
as
well.
I
Is
that,
like
our
view,
is
that
there
is
like
an
old
world
in
a
new
world
and
we
want
to
like
not
have
a
lot
of
steps
in
between,
but
what
I
mean
by
that
is
like.
We
don't
want
you
to
take
sort
of
a
lot
of
piecemeal
upgrades
into
the
same
codebase
because
it
just
makes
the
migration
all
that
much
more
difficult.
So
like
we
know
that
we
are
probably
not
going
to
maintain
two
versions
of
every
comic.
We
are
probably
going
to
just
maintain
the
codecs
for
this
new
stack.
I
So
I
actually
wrote
a
legacy
interface
so
that
you
can
take
a
new
style
codec
and
it
will
completely
convert
that
into
the
interface
you
currently.
So
it
literally
converts
back
to
buffer
it
converts
to
the
old
CID
interface,
like
everything
should
look
the
same,
and
it
should
have
the
same
structure
to
it
that
you
would
plug
into
I.
Think
it's
gsib
format
or
something
like
that.
I
A
I
Yeah
I
mean
if,
if
the
changes
were
not
to
value
types,
I
think
that
we
can
do
that
pretty
easily,
but
changing
a
value
type
it
is,
is
just
substantial
like
it's
not
it's
not
a
one.
It's
not
a
small
PR,
and
it's
also
like
something
that
impacts
the
ecosystem
on
top
of
Jays
idea.
That's
right
like
this.
Isn't
this
isn't
changing
if
I
confess
it's
a
change
to
like
all
the
libraries
just
using
because
they're
not
getting
a
buffers
anymore,
like
they're,
not
gonna,
get
the
old
CID
in
a
fix
anymore.
I
So,
like
that's
just
it's
not
something
that
you
can
kind
of
take
piecemeal,
I,
think
the
closest
thing
that
we
could
do
is
and
there's
an
example
of
this
is
the
CLI.
We
sent
a
PR
for
import
and
export
of
car
files,
and
that
uses
our
new
interface
and
it's
isolated
to
only
the
CLI,
so
it
doesn't
impact
like
the
whole
rest
of
the
stack
and
doesn't
have
to
like
and-
and
it
can
be
kind
of
disentangled,
and
if
you
notice
like
in
that
code
path,
it
actually
is
pulling
in
the
new
book.
I
The
old
version
of
the
new
block
interface
and
now
we'll
get
upgraded
actually
to
like
the
very
very
new
stuff
and
in
your
future,
but
like
that's
the
kind
of
thing
that
we
we're
really
looking
for
opportunities
to
send
you
to
get
feedback
on
so
yeah.
It
would
be
great
like
if
you,
if
you
could
look
at
that
PR
and
also,
for
other
reasons,
I
think
that
we
do
need
to
to
close
that
out
and
figure
out
what
we're
gonna
do
for
the
import
and
export.
I
But
yeah
yeah
like
that.
That's
really,
as
far
as
we
can
go
just
because
the
value
type
change
is
such
a
big
big
deal
yeah!
It's
not
really
something
that
we
can.
We
can
do
on
a
small
basis.
I
wish
that
there
was
like
a
better
example,
but
just
like
I
think
one
thing
that
might
really
help,
though,
and
it'll
be
a
little
different
for
you,
but
at
some
point,
GSI
PFS
light
will
take.
I
This
API
will
work
we
closely
with
them
on
that
and
pulling
you
all
into
that
PR
just
to
look
at
the
code
and
see
some
of
the
differences.
I
think
will
be
really
educational
to
think
about
how
they're
gonna
change.
This
would
have
to
be,
for
guess,
ipfs
for
instance,
and
like
I,
yeah
I,
don't
I,
don't
know
I
don't
want
to
get
back
to
the
conversations
were
having
before,
but
it
may.
I
It
may
even
be
worth
considering
like
a
future
version
of
Jas
ipfs
being
on
line
of
code
on
top
okay
SIDS
like
and
if
that
was
an
easier
way
to
make
the
upgrade
that
that
might
also
be
a
road
that
you
might
want
to
consider.
But
yeah
I
mean,
like
I,
said
like
this:
isn't
my
project
like
I,
can't
I
can't
make
a
lot
of
these
decisions
for
you,
but
yeah
I
mean
we'll
do
what
we
can
we'll
keep
doing
stuff
like
the
car
import/export.
Let
me
see.
I
So
there
is
no
timeline
for
that
and
go
like
we
like.
This
is
like
a
thing
that
we
know
needs
to
happen
someday,
but
there's
like
there's
no
prioritization
to
it.
It's
not
what
we're
so
constrained
for
the
resources
and,
as
you
can
imagine,
they're
so
like
allocated
to
file,
claim
that
there's
just
like
there's.
No,
nothing
close
to
a
date
on
this
rust
is
is
doing
this
right.
H
Like
I
have
a
question
based
on
your
comments
that
you
made
earlier,
which
was
you
only
have
an
adapter
that
can
take
the
new
codec
implementation
and
turn
it
adapted
to
the
current
codec
implementation?
Is
there
a
reason?
Why
would
not
existing
codec
library
just
use
an
adapter
and,
like
proxy,
choose
a
new
implementation?
So
you
don't
have
two
different
versions
coding
so
because
that's
been
essentially
mentioned
you
in
a
dress
as
ice
thing
and
doing
a
lot
of
work
trying
to
get
you
in
a
day
race
across
all
these
codecs,
but
the
old
ones.
I
H
I
Doing
that
and
didn't
mainly
because
the
old
codec
interface
has
so
much
extra
kind
of
boilerplate
and
endpoints
that
there's
not
like
a
discrete
single
place
where
you
can
do
the
translation.
Yes,
did
you
put
in
multiple
places,
and
so
we're
just
like
you
know
what
it's
probably
easier
for
us
to
just
port
the
old
codex
over
to
the
new
style
and
then
export
this
legacy
interface
like
it's?
H
That
ipfs
light
is
actually
bad
and
you're
talking
about
maybe
talking
working
with
this
textile
to
get
a
new
IP
all
these
stuff
and
maybe
I
guess
could
be
on
her
website.
So
all
of
these
things
kinda
interconnect
so
one
things
that
I
wanted
wanna
do
and
figure
out
how
is
and
I
took
to
Carson
about
it
too.
So
Doug
API,
essentially
is
a
block
API
with
some
the
encoding
decoding
happening
under
the
hood
and
the
block.
Kk
is
kind
of
nice
because
it's
much
more
smaller
API.
B
H
Is
there
any
way
we
could
have
that,
so
that
block
API
can
be
agnostic
of
the
block
implementation,
new
versus
old
one?
So
people
who
want
to
try
the
new
IP
all
this
stuff
can
do
so
by
using
mu,
I
kill
the
block
and
the
I
cap
has
block
API,
and
if
they
don't
want
to
do
that,
then
they
can
continue
using
dag
API.
At
least
that
would
be
really
interesting
for
me
to
do
the
shared
node
thing,
because
that
would
address
the
use
case
that
Excel
has,
with
their
ipfs
lights.
H
I
I
H
A
low
KPI
is
it
just
more
like
a
binary,
API
choose
a
block,
store
and
IPL
d
blog
gives
you
a
way
to
create
those
binaries
and
because
those
miners
and
duggie
api
sorta,
while
people
wanted
migrated,
sir,
but
hopefully
they
will
migrate
and
it
will
be
unnecessary
in
the
future
because
block
a
like
I,
kill,
D
block
and
block
a
pair
will
kind
of
do
all
of
the
things
already.
Does
that
make
more
sense.
I
Kind
of
I
mean
like
isn't
that
really
easier?
Like
you
know,
it's
would
no
more
than
me,
but,
like
can't
I
think
it's
called
my
like
the
block
service
interface
right
like
can't
you
just
instantiate
that
and
get
it
on
the
network
and
everything.
And
then,
if
you
have
that
block
service
interface
insane
because.
I
I
Okay,
all
right
yeah,
hopefully
I
cleared
that
up
yeah
we're
not
trying
to
make
like
a
ton
of
extra
work
for
you.
We're
actually
trying
to
do
the
opposite
and
trying
to
limit
the
number
of
grades
that
you
all
have
to
take
and
and
just
like
make
sure
that
we
get
things
right
so
that
when
you
upgrade
you're
not
constantly
sort
of
driving
through
a
bunch
of
other
issues
that
we
hadn't
uncovered
yet
I.
E
I
I
mean
like
yeah,
so
so
one
is
that,
like
the
new
interfaces
for
go
are
coming
along
in
there
and
there
and
they're
pretty
far
along
now,
I
mean
like
they're
used
in
grabs
tank,
for
instance,
I.
Think
that,
like
again
like
we,
we
have
a
much.
We
have
a
resourcing
issue
across
the
board
for
things
that
aren't
coined
and
that
Menace
particularly
deeply
felt
on
the
go
resource
inside.
I
E
G
I
I
But
then
at
some
point
we're
gonna
need
to
let
go
into
each
language
and
say
like
this
is
the
best
way
to
do
that
for
these
different
interfaces
and
yeah
I
think
that
a
lot
of
the
time,
actually
no
I
I
can
guarantee
you
that
for
every
language,
we'll
just
have
like
okay,
here's
how
to
get
that
into
a
car
file
like
whatever
you
just
did.
He'll
come
to
get
a
new
car
file
and
then
here's
how
our
files
go
into
IP
address
and
file.
I
E
I
E
I
We're
starting
with
like
here's,
what
an
in-memory
map
looks
like
in
your
language.
That's
a
data
structure.
Here's
like
what
it
looks
like
when
we
turn
that
into
something.
That's
an
IPL
d
where
we
get
this
hash
board
and
you
can
go,
get
it
and
then
from
there
like
that
becomes
a
link,
and
this
is
how
you
create
a
data
structure.
It
links
to
different
parts
of
the
thing
and
that's
how
you
build
bigger
structures.
They
go
over
that
limit
like
that.
That
is
definitely
something
we're
working
on
that
we'll
have
well.