►
Description
Access more meeting details at: https://github.com/ipfs/team-mgmt/issues/992#issuecomment-661124031
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
Hi,
everyone
welcome
to
the
ipfs
core
implementations
weekly
sync
from
monday,
the
20th
of
july
2020.,
it's
a
lot
of
20s
in
the
date
today
we're
going
to
go
through
all
our
initiatives
and
then
go
through
questions
and
blockers
and
asks,
and
that
sort
of
thing
so
for
the
high
priority
initiatives.
The
first
thing
is
upcoming
and
ship
releases,
so
we
shipped
js
ipfs
0.48,
which
is
great
so
that
gave
us
delegates
on
by
default.
A
B
Releases
nope,
I
think
my
current
thinking
is
that
we're
probably
just
gonna
bundle
zero
six
one
with
zero,
seven,
just
because
there's
there's
a
bunch
to
do
and
we'd
rather
release
zero,
seven
sooner
rather
than
later,.
A
Fair
enough
moving
on
pinning.
C
Oh
yeah
I'll
go
yeah,
so
there's
a
the
api
and
client
development
should
be
unblocked.
Now
we've
got
like
basic
approval
on
the
spec.
Nothing
big
should
change.
There
may
be
some
some
small
tweaks
as
we
go
along,
but
that
should
be
ready
to
implement.
C
I
need
to
create
a
issue
in
go
ipfs
to
track
implementation
of
the
client
and
go
and
then
whatever
other
things
that
we
need
for
ipvs
desktop
to
be
able
to
hook
into
that.
We
can.
We
can
flush
out
in
that
issue,
but
from
there
we
should
be
should
be
good
to
go
and
all
unblocked
for
for
moving
forward
with.
C
C
And
then
I
will
just
move
on
to
ed
keys,
since
that
is
next.
So
the
there's,
the
tracking
issue
there
for
go,
there's
a
couple.
There's
a
few
things
left
that
need
to
get
cleaned
up
there,
like
ips
key
output,
there's
some
sharness
test
issues,
but
nothing
I
don't
think,
there's
anything
major.
There
left
15
right.
B
Nothing
major
we
may
probably
as
bundling
this.
We
should
at
least
in
go
multi-adder,
add
support
for
base
36
encoding
or
like
yeah
cidv1
encoding
at
all
and
go
multi-outer,
but
it
shouldn't
be.
It
shouldn't,
be
a
big
deal.
C
Yeah
and
then
the
other
one
issue
that
was
blocking
that
was
interrupt
with
js
and
the
big
problem
there
was
jess,
wasn't
able
to
unmarshal
go
keys
so
a
while
back
go
changed.
C
There
was
an
issue
where
loot
p2p
was
taking
the
ed
keys
and
encoding
them
as
like
private
public
in
your
private
key.
That
also
include
your
public
key
already
when
that
gets
marshaled,
but
we
were
also
appending
the
public
key
again,
so
it
was
redundant
and
go
got
rid
of
that
a
while
ago,
but
js
didn't,
and
so
when
we
go
to
unmarshal
the
go
keys,
we
fail
because
the
cookie's
not
long
enough
because
we're
expecting
that
extra
public
key
in
there.
C
So
that
is
fixed
and
I
just
released
an
update
to
the
pdb
js
crypto
today.
That
includes
that
fix.
I
didn't
change.
How
js
is
marshaling
the
key
to
avoid
breaking
change
so
we'll
continue
to
put
the
redundant
public
key
in
there
for
now
because
go
handles
both,
but
later
I'll
get
rid
of
that
to
avoid
any
breaking
changes.
But
I
don't
think
too
many
people
are
using
82519
in
js
ipfs
because
they
can't,
because
it
breaks
and
along
with
that,
along
those
lines.
C
The
problem
that
we
have
with
jas
using
ed
keys
is
importing
and
exporting
keys
that,
like
the
way
js
is
handling
it.
It
exports
and
imports
keys
into
the
keychain,
based
on
it
being
formatted
as
a
pem,
but
that
is
like
support
for
there
in
js
is
atrocious
across
the
board.
Just
crypto
and
js
is
is
rough
and
then
also
balancing
bundle
size
in
the
browser
is
a
bit
of
a
nightmare.
C
So
what
we're
likely
going
to
look
at
doing
I
talked
with
alex
a
bit
today
is
to
just
for
the
ed
keys
and
like
sccp
keys
to
just
change
those
over
to
import
and
export
as
protobufs,
because
that
is
the
p2p
default
and
then
later
make
rsa.
Do
that
also,
and
then
one
of
the
requirements
is
that
we
also
support
like
just
password
encoding
of
those
keys.
C
So
what
we'll
likely
do
is
just
take
the
lipid
protobuf
and
then
add
just
like
symmetric
password
encryption
on
that
and
then
export
that
so
that
it
still
has
that
same
behavior
but
will
default
to
the
protobuf.
This
will
be
like
the
easiest
and
quickest
fix
that
we
can
get
for
jsipfest
to
be
able
to
start
using
id
keys.
C
If
anybody
has
concerns
there.
Let
me
let
me
know
eventually
we'd
like
to
support
pen
in
a
variety
of
other
formats,
but
that's
going
to
require
a
significant
overhaul
of
liberty
crypto
to
do
that.
B
Yeah,
I
guess
two
things
one
is:
is
there
any
reason
why
go
ipfs
needs
to
be
able
to
deal
with
the
password
stuff
like
ipvs
has
like
a?
We
will
decode
password
encrypted
private
keys
function.
That
just
does
nothing
right
now,
because
it
was
never
implemented.
Do
we
have.
C
To
implement
that
so
go
doesn't
export
keys
at
all.
Like
you
can't
yes
for
keys
and
go
in
js,
you
can
so
you
can
export
them,
and
so
that's
that's
the
big
difference
there,
and
so
that's
really
what
we're
we
need
to
support
that,
because
that
functionality
is
leveraged
by
ipns
to
get
the
get
the
keys
out.
C
D
B
C
Yeah,
I
think
the
main
concern
that
the
api
is
trying
to
handle
is
that
the
the
api,
the
keys,
are
encrypted
when
they're
stored.
That's
the
big
thing
there
is
that
their
password
encrypted
when
they're
stored,
so
they're
not
just
stored
unencrypted.
C
That's
like
the
big
thing
from
the
api
key
we
do
support
like
we
do
support,
at
least
in
ed
keys
in
js.
We
support
creating
from
from
a
seed
which
could
be
a
password,
so
you
can
actually
derive
from
the
seed
with
ed
keys,
but
I
don't
think
we're
actually
using
the
seed
creation
anywhere
in
in
ipfs
ecosystem
for
js.
I
think
that's
just
a
somebody's
wanted
that
in
libpdp,
so
we
support
it.
C
D
C
Would
say
that
there's
not
a
good
reason.
There
may
have
been
a
good
reason
like
two
or
three
years
ago,
but
that
was
two
or
three
years
ago.
That
code
like
keychain
and
crypto
have
been
very
untouched
in
the
last
couple
of
years
and
it
it
needs
an
overhaul
and
an
update
like
that
whole
api
of
crypto
needs
an
overhaul.
So
in
theory
I
don't
think
there's
anything
stopping
us
from
using
system
keychains,
but
we
would
just
need
to
validate
that
or
evaluate
it.
Rather.
E
F
Yeah,
so
the
remaining
task,
as
far
as
I
know,
is
shipping
go
ipfs
0.7
with
that
fix
for
eddy
keys
in
subdomains
and
coded
in
base
36
and
writing
a
blog
post.
But
we
could
probably
move
this
section
to
other
initiatives
or
yeah.
G
Yeah,
I'm
sort
of
making
up
for
the
past
few
weeks
when
I
haven't
been
around
and
we've
been
busy,
the
biggest
piece
of
news
is
the
ad
functionality
so
unix
unixfs
importing
now
is
working
for
single
files.
It's
still
a
little
shaky,
but
we're
we're
getting
through
it.
It's
just
functionality
that
touches
a
huge
breadth
of
of
things.
G
Inside
of
fpfs
we've
improved
our
conformance
testing
workflow
a
lot
using
git
patches,
so,
instead
of
submitting
pull
requests
to
jsipfs
we're
just
patching
it
locally,
just
to
change
some
of
the
apis
that
we
need,
and
now
what
we're
working
towards
is
getting
the
rest,
ipfs
nodes
to
bootstrap
and
swarm
globally
with
content,
discovery
and
content,
providing
want
list
and
all
that
stuff.
So
you
can
look
through
the
pull
requests
that
I've
linked
here.
G
The
other
thing
is:
there's
some
http
api
improvements,
most
notably
the
streaming
multi-part
work
to
update
all
that
and
some
rust
api
improvements
like
arc
archifying,
some
of
the
inner
ipfs
structs
to
make
them
easier
to
pass
around
and
do
multi-threading
work
and
we've
also
added
the
bores
tool
for
build
and
pull
request,
approval,
automation
and
things
like
that.
So
all
across
the
board,
things
are
getting
faster
and
more
featureful.
I
suppose
that's
all
from
us.
A
That's
awesome:
next
up
is
jessica,
p2p
sign
peer
records
and
gossip
sub
review,
1.1.
H
Yeah,
so
for
the
record
side
of
things,
jacob
got
everything
reviewed
last
week
and
basically
the
prs
for
the
interface
record.
The
peer
record
and
envelope
implementation
were
also
merged
for
the
0.29
release.
Branch
ended
together
with
the
exchanging
of
the
design
peer
records
in
the
identify
protocol.
H
So
for
this
part
of
things
to
get
done,
we
just
need
to
have
the
certified
address
book
pr
merge,
which
was
also
reviewed
in
the
the
review
address,
so
I
think
it
should
be
ready
or
mostly
ready
to
be
merged
in
the
gossip
sub
side
of
things.
We
are
basically
refactoring
the
base
web
sub
implementation.
H
This
thanks
to
all
the
work
that
came
and
did
in
the
gossip
server
update.
We
basically
wanted
to
extract
some
of
that
work
to
the
base
implementation
so
that
the
flood
syllabus
will
leverage
it
and
yeah.
Also
gossip
after
this
we'll
need
to
get
the
scientific
records
also
integrated
in
the
peer
exchange,
pr
which
is
currently
in
progress,
and
with
that
we
will
need
to
start
looking
into
the
interrupt
tests.
And
for
that
for
this
we
are
currently
blocked
on
some
gold
b2b
demand
updates.
H
It
would
be
great
if
anyone
from
the
gofox
could
get
that
landed
and
yeah.
That's
everything
from
the
gossip
side
of
things.
Yeah
I
mean
moving
to
the
next
section.
I
basically
renamed
it
from
rendezvous
to
js,
improves,
discoverability
and
connectivity.
H
Basically,
because
we
will
be
looking
into
a
broader
scope
of
what
we
want
to
achieve
and
from
one
side
is
rendezvous,
but
we
are
we.
If
you
look
at
the
issue
that
I
linked,
there
are
other
things
that
jacob
created
that
will
be
our
path
in
order
to
improve
this
side
of
things
and
so
in
the
rendezvous.
H
H
I
also
need
to
integrate
the
thank
you
records
in
the
rendezvous
and
I'm
also
working
on
a
proposal
for
guaranteed
who
has
a
discovery
protocol
like
the
other
ones,
so
that
we
can
basically
leverage
out
of
the
box
everything
that
the
other
discovery
services
do
like
the
peer
discovery,
events,
and
also
to
add
everything
to
the
address
book
without
any
user
manual
work
and
also
allow
power
users
to
do
them
do
that
themselves
if
they
wish
to
and
yeah
and
after
the
fender
for
getting
to
a
state
of
review.
H
H
It's
too,
there
is
currently
one
pr
to
basically
upload
to
goalie
ptp
dim
and
go
mod
to
use
the
later,
not
the
latest,
but
the
previous
latest
release
of
just
people.
It
would
be
good
to
have
both
so
that
we
can
test
interrupt
with
the
latest
two
releases
of
goalie
hp.
A
Okay
cool,
so
that's
the
end
of
the
the
main
initiatives
section
moving
on
to
the
other
initiatives,
so
you
need
suffice
for
1.5,
there's
no
update
really
on
the
go
ipfs
issue,
somebody
volunteered
to
pick
up
the
work,
so
that's
quite
exciting.
A
The
migrations
multi-hash
keys
in
the
block
store
that
are
shipped
in
jsi
pfs
now,
so
that's
cool
the
next
section
for
the
pinning
system
revamp
I'm
going
to
pick
that
up
this
week,
but
I
want
to
get
all
of
iraqi's
changes
in
because
I'm
feeling
like
a
bit
of
a
bottleneck
to
a
lot
of
that
stuff.
So
I'm
going
to
concentrate
on
that
and
then,
hopefully,
later
in
the
week,
pick
up
the
pending
system,
stuff.
D
Yeah,
so
I
did,
I
think
I
got
the
I
put
them
in
the
wrong
place.
My
notes,
sorry
and
I
did
the
example-
choose
a
shared
ipfs
node
that
demonstrates
using
it
kind
of
like
we
have
other
examples.
D
The
next
one
is
improving
web
file
ad,
which
is
so
we
had
a
conversation
with
alex
and
hugo
and
decided
to
pull
out
the
file
and
blow
pieces
out
of
the
js
ipfs,
which
I
did
and
published
as
a
libraries
linked
in
the
notes
I
have
pulled
in
and
integrated
changes
for
ipfs
and
at
all
separation
in
there
and
update
it
pull
request.
D
I
added
a
bunch
of
tests
to
try
to
catch
all
kind
of
regressions
that
might
happen
in
our
ad
input
normalization
to
make
sure
that
down
the
line,
we
don't
regress
in
improvements
and
yeah,
so
the
pull
request
now
is
blocked
on
review.
D
The
other
thing
is,
we
do
have
another
patch
for
the
web
ui
that
is
supposedly
fixed
set,
which
is
the
primary
use
case,
which
kind
of
waits
on
the
changes
in
js
ipfs
to
land
before
we
can
take
them
in
there.
Also
one
thing
that
came
to
my
mind
that
maybe
it
is
worse
landing
that
pull
request
without
waiting
waiting
for
js
ipfs
right
now
it
does
optimization
like
by
just
consuming
jsi
pfs
http
api
directly
and
once
jsipfs
changes
lens.
D
Then
we
can
rip
that
piece
out
and
make
use
of
js
ipfs.
I
don't
know
if
that's
what's
doing
or
not,
but
if
we're
having
a
time
pressure,
we
could
consider
doing
that
too.
B
B
I
think
this
is
just
because
of
an
issue
where,
like
we
were,
we
kept
around
the
whole
looking
for
public
keys
separately
from
ips
records,
which
has
been
obsolete
for
a
while.
I
have
a
pr
that
I
think
should
fix
this,
but
it
would
be
great
if
someone
could
run
it
with
the
interop
tests.
B
G
G
You
know
things
of
that
nature
and
I'm
wondering
the
question
is:
should
we
move
ahead
now
with
something
like
powergate
to
integrate
with
filecoin,
or
should
we
wait
for
the
pinning
api
to
be
more
quote
ready,
or
should
we
collaborate
and
figure
out
if
orbitdb
you
know,
can,
can
help
smooth
out
some
of
the
use
cases,
or
things
like
that,
and
I'm
wondering
if
anybody
here
would
be
willing
to
hop
on
probably
a
different
call
or
just
email
with
me
or
something
to
hash?
Some
of
that
out.
C
Yeah,
I
think
maybe
leitel
and
I
could
hop
on
and
talk
about
that.
I
think
like
that,
might
depend
what
you
want
to
do
because,
like
right
now
that
the
painting
service
spec
is
very
like
it's
very
basic,
because
we're
not
sure
like
what
that's
going
to
look
at
long
term
and
there's
like
a
lot
of
discussion
around
okay.
Let's
change
pinning
to
actually
like
just
be
like
pin
threads,
but
we
need
to
do
a
lot
more
work
to
flush
that
out.
So
I
think
like.
C
G
B
Lot,
oh,
I
guess
I
had.
I
I
put
up
a
pr
for
a
dag
size
command.
Apparently
I
was
yes.
You
know.
I
was
recently
informed
that
there's
no
easy
way
or
you
can
just
ask
for
the
size
of
a
dag
without
it
being
unix
fs
and
relying
on
the
field.
That's
in
unix
fs,
so
there
there
is
a
prototype
of
what
that
would
look
like
in
a
pr
to
go
ipfs.
E
Yeah
a
month
or
so
back,
I
spent
some
time
explaining
to
pinata
that
they
can't
really
trust
the
number
in
unix
fs
and
that,
like
people
could
lie
so
we
we
should
definitely
document
them
somewhere
and
having
this
command
to
point.
People
out
would
be
super
useful
because
it's
like
an
actual
real
world
kind
of
trusted
thing
that
you
could
do.
A
Yeah,
it's
super
useful.
If
you
stick
a
link
in
the
in
the
notes
for
that,
that
would
be
rad.
E
The
one
the
one
thing
that
we
we
did
in
the
the
data
structure
screen
xsp2
for
this
and
the
flexible
byte
layout,
which
handles
kind
of
like
the
layout
for
all
the
bytes.
If
you
lie
about
the
size
anywhere,
it
means
that
you
can't
really
read
the
data
structure
efficiently,
so
it
actually
breaks
things
when
you
lie
that
was
like,
as
far
as
we
could
really
get
to
to
make
it
less
likely
or
disincentivize
people
to
lie
about
the
size.
B
It
does
skip
duplicates
so
there
is
that,
but,
like
you
could
be
smarter
and
do
things
like.
Don't
actually
read
the
don't,
actually
read
raw
blocks
into
memory,
because
you
know
that
they're
not
going
anywhere,
you
could
just
get
the
size
from
disk,
and
that
would
be
enough
things
things
like
that.
But
for
now
it's
like
better
than
nothing
so
better
than.
E
Nothing
so
this
is
kind
of
random,
but
somewhat
related,
I'm
working
on
an
a
potential
upgrade
to
the
car
file
format
that
will
stick
a
manifest
at
the
end
of
it,
and
so
the
manifest
would
allow
you
to
seek
into
the
the
car
file
and
actually
read
things
out
without
having
to
to
do
full
parses
of
the
of
the
file
or
even
for
parts
of
the
block,
and
so
we're
sort
of
figuring
out
like
what
should
and
should
be
in
this
manifest.
E
But
one
thing
that
will
obviously
be
in
there
is
like
block
sizes,
but
I'm
debating
about
whether
to
or
not
to
even
put
like
link
information
in
there
so
that
it
presents
you
kind
of
a
full
picture
of
the
the
links
in
the
dag
without
ever
having
to
parse
out
anything
in
the
file
or
decode
anything,
and
that
would
really
help
with
stuff,
like
this,
like
you'd,
be
able
to
calculate
dags
without
ever
decoding.
E
B
A
But
there
we
are
at
time.
Thank
you
all
for
coming
to
the
core
implementations
which
you
think
for
the
20th
of
july
2020.
Please
fill
out
your
async
updates
in
the
notes.
If
you
haven't
done
already
and
we'll
see
you
next
week
say
stay
for
everyone.