►
Description
Access more meeting details at: https://github.com/ipfs/team-mgmt/issues/992#issuecomment-664459148
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
and
welcome
to
the
ipfs
core
implementations
weekly
sync
for
monday,
the
27th
of
july
2020.,
I'm
picking
brain
I'll,
be
your
host.
We're
going
to
go
through
our
high
priority
initiatives
or
other
initiatives
have
q
a
design
review
proposals
parking
lot.
That
kind
of
thing
super
good,
so
kicking
off
the
high
priority
initiatives
is
upcoming
and
ship
releases
did
anybody
ship
anything.
B
We
do
have
a
tracking
issue
for
go
ipfs
0.7.
I
will
add
that,
but
that
is
not
slated
to
release
still
later
in
august.
A
Cool
I'm
hoping
to
release
49
of
js
ipfs
later
this
week
that
will
contain
oracle's
work
on
a
shared
ipvs
note
between
tabs.
It
will
include
new
the
new
pinning
refractor,
so
pins
stored
in
the
data
store,
which
will
be
lightning
fast
for
adding
and
a
host
of
other
small
bug
fixes
so
yeah.
Hopefully,
that
will
be
out
by
the
end.
A
So,
moving
on
to
the
next
high
priority
initiative
is
the
pinning
services.
Please
do
you
have
an
update.
B
So
we've
got
the
issue
stubbed
out
for
that
the
spec
is
pretty
much
done.
There
might
be
some
small
tweaks
along
the
way.
I
think
there's
a
created
time
issue
there
a
time
stamp
for
created.
I
need
to
look
at
that
and
review
that,
but
other
than
that
that
work
should
be
ready
to
start.
I
think
we'll
likely
wrap
up
the
ed
key
work
and
then
move
on
to
to
that.
A
Awesome
is
there
any
further
update
on
the
ed25519
keys.
B
Yes,
there
we
were
words,
there
was
an
issue
we
were
currently
sorry.
Brain
sharna's
tests
are
fixed.
Now
we're
looking
at
the
petars
pr
open
for
finishing
up
the
iip
next
keys
as
base
36
by
default.
B
There
was
some
nice
to
haves
that
I
think
dean
was
looking
at
in
terms
of
pure
ideas
base
36
cids
dean.
Did
you
want
to
talk
about
that.
C
Yeah,
I
think
we're
likely
going
to
leave
the
priorities
as
being
emitted
as
base
58
multi
hashes
by
default,
but
we
definitely
need
to
make
go
multi,
adder,
parse
base,
36
or
parse
cids,
so
yeah
just
so
that
we
can
do
this
in
the
future,
with
with
less
problems.
B
Yeah,
so
we
are
currently
working
on
planning
the
removal
of
sec-io.
This
is
a
long
time
coming.
Sakaio
was
never
meant
to
be
a
permanent
thing.
Now
that
libby
noise
support
is
out
we're
gonna,
look
at
setting
a
timeline
for
rolling
out
the
removal
in
go
ipfs
tentatively,
we're
targeting
0.7
for
that,
and
then
we're
currently
evaluating
this
week.
Looking
at
what
pl
infrastructure
we
have
up
and
then
kind
of
the
rollout
of
that
secio
removal.
B
We're
also
trying
to
be
cognizant
of
especially
things
like
js
ipfs,
like
upgrading,
because
only
four
seven
has
the
pdp
noise.
We
have
the
ability
to
add
noise
like
backwards
compatible
down
to
like
oh
41,
I
think,
but
really
figuring
out
making
sure
that
we
have
the
support
there
for
the
various
implementations
to
allow
for
that.
So
we're
going
to
be
working
this
week
on
communication
of
that.
B
What
the
rollout
plan
looks
like
for
that
and
then
trying
to
help
support
teams
with
upgrading
either
just
updating
configs
like,
for
example,
using
orbitdb
like
if
you're
gonna
right
now,
I
think
it's
still
on
ob46.
So
in
theory,
you
can
just
plug
in
lippy
to
be
noise
to
that
version
of
ipfs,
but
making
sure
that
there's
a
clear
path
for
people
to
be
able
to
do
that.
We
want
to
make
sure
that
we
we
have
that
support.
So
we're
evaluating
that
this.
A
Week
are
we
going
to
be
able
to
pull
out
any
of
the
peter
p's
crypto
dependencies
if
we
don't
need
sakai
anymore.
B
That
is
a
good
question.
Maybe
I'll
have
to
look
at
that.
E
Cool
next
up
the
rust
ipvs
initiative,
lots
of
lots
of
activity
here.
F
Hey
everybody
yeah,
so
the
big
news
is
that
dht
and
content
discovery
is,
is
working
now,
so
we're
one
step
closer
to
getting
a
bootstrap
pier
that
can
connect
with
the
global
swarm
and
get
intent.
Content
we've
already
rewritten
the
unix
fs
adding
component.
But
it's
much
better
now
and
the
final
little
bit
of
fun
is
that
I
spun
up
an
orbit
db
node
and
tried
to
interface
with
rust
ipves
via
the
http
apis,
like
you
would
a
go
node
and
it
almost
worked.
F
I
was
expecting
a
lot
of
like
http
errors
and
stuff,
but
we
have
over
150
passing
conformance
tests
now
by
the
http
api.
So
it's
it's
really
close
to
being
there
there's
a
couple
persistence
issues
to
work
out,
but
we
should
have
full
compatibility
there
pretty
soon
too.
A
I've
been
looking
into
the
like
the
timeout
stuff
as
well
trying
to
pull
out
the
like
default
timeline.
Basically,
what
happens
is
when
you
pass
a
timeout
argument
to
any
api
call.
It
sets
the
timeout
on
the
client
as
well
as
the
server,
so
I've
been
looking
at
pulling
it
out
from
the
client
nearly
there
with
that,
but
it's
still
a
little
bit
done.
So
it's
a
little
bit.
That
needs
to
be
done
to
finish
that
off.
A
H
So
in
the
signed
peer,
reviewer
side
of
things,
the
the
last
pr
that
we
had
opened
was
for
the
certified
address
book.
It
is
now
merged.
So,
in
this
site
of
initiative,
we
have
everything
now
merged
in
the
lipid
peak
core,
more
precisely
in
the
0.29
branch
that
we
will
merge.
When
do
we
do
the
release
and
gossip
sub
1.1
in
rendezvous
working
progress?
Branches
already
are
using
this
version
and
yeah
in
the
gossip
server
1.20
side
of
things.
H
Basically,
the
peer
exchange,
pr
which
included
the
sample
records,
was
also
merged
in
the
branch
for
the
1.1
and
cayman
is
now
currently
working
on
more
tests,
he's
basically
inspiring
on
the
go
implementation
tests
and
is
guaranteeing
that
all
the
flaws
that
go
is
testing.
We
are
also
testing
in
js,
which
I
think
it's
a
good
call.
So
for
closing
this
initiative,
we
basically
need
to
close
the
working
progress
step
that
we
already
have.
H
There
is
this
test,
and
also
there
is
the
refactor
of
the
base
implementation
of
pub
cell
and
with
that
update
flood
sub
and
go
into
the
interrupt
tests
with
go
and
yeah.
That's
pretty
much
about
the
signpl
hackers
in
gossip,
so
for
the
improved
discoverability
and
connectivity
in
js.
H
So
there
are
hindu
work,
it's
mostly
ready
for
review.
Again.
I
did
a
pr
to
play
the
spec
with
the
signed
peer
record.
I
also
aligned
with
jacob
last
week
or
now
we
should
integrate
renew.
H
We
will
start
by
using
it
as
an
external
module
and
eventually
as
soon
as
we
flush
out
better
the
the
api
and
we
get
feedback
from
the
first
users,
we'll
eventually
move
it
inside
liquid
speed
car,
but
for
now
we'll
have
it
outside
and
yeah.
The
work
is
ready
for
the
view,
but
I
think
it
will
not
be
a
priority
at
the
moment.
H
I
need
to
sync
with
jacob,
but
maybe
we'll
wait
for
the
0.29
before
getting
into
it
again
and
yes,
so
I
will
also
start
working
this
week
on
the
other
piece
of
the
this
initiative,
which
will
be
the
authorial
and
that's
it
from
me.
B
Just
in
regards
to
gossip
sub-
I
don't
know
if
you
saw,
but
I
guess
there
were
some
issues
in
like
rust,
that
caused
a
problem
with
go
lippy
piece,
so
go
lippy
to
p2p
pub
sub,
like
the
message
ids
that
come
across
in
the
protobuf,
those
are
strings
and
I
think
like
they
will
be
go
as
interpreting
those
as
utf-8,
which
is
problematic,
because
people
are
sending
non-utf-8
strings
and
so
that
creates
issues
on
the
go
side
of
things
and
so
like
the
spec
is
updated
now
to
just
change,
meshes
ids
over
to
bytes
and
so
we'll
likely
need
to
look
at.
B
We
should
probably
look
at
for
gossip
sub
1
1,
also
just
going
in
and
figuring
out
like
okay.
Let's,
let's
do
that
conversion.
I
don't
think
it
should
be
like
too
big
of
an
issue
in
js.
Just
because,
like
we're
not,
I
think
we're
just
using
it
for
hashing,
but
we
should.
We
should
check
that
out.
B
There's
an
issue
in
jslippy
to
be
pub
sub
I'll,
just
link
that
in
the
chat
and
put
it
in
the
notes
that
references
this
issue
that
links
to
all
of
the
the
go
go
issues
and
issues
and
rust.
So
we
should
probably
try
to
make
sure
that
we're
supporting
that
sooner
rather
than
later,
for
whenever
go
actually
switches
over.
H
A
That
is
it
for
the
the
high
priority
initiatives.
In
the
other
initiatives.
There
is
no
update
on
the
sub
domain
gateway.
I
can
see
pending,
go
okay,
there's
1.7
blog
posts
and
docs.
A
I'm
not
going
to
ask
you
to
do
it
any
further
update,
because
there's
an
update,
I'm
ready
to
sell
it.
Okay,
cool
unix,
v1.5
and
go
ipfs,
because
the
update
is
justice.
Node
has
appeared
and
is
going
to
take
on
the
implementation
of
unique
successfully
1.5
in
go
ipfs
he's
spinning
up
by
the
looks
of
the
issue.
I
will
post
a
link.
A
Moving
on
the
migration
to
multicast
keys
in
the
block
store,
that's
shipped
in
the
last
version
of
church
wfs,
so
that
can
be
closed
and
removed.
Pinning
system
revamp
is
yeah.
It's
really
close.
I
just
want
to
take
a
final
pass
over
garbage
collection
around
the
depth
property
of
the
pens,
but
that
should
be
just
like
an
eyeball.
Well
right,
lots
of
tests
kind
of
operation,
it's
small
super
good
to
get
that
done.
Shared
ipfs
node
is
the
next
thing
to
talk
about
goes
up.
I
Okay,
sorry,
I'm
muted
yeah.
It's
landed,
I'm
very
excited
thanks,
alex
for
leaving
and
learning
there'll,
be
more
work
happening
on
that,
namely
I'm
I've
been
mentioning
in
a
couple
of
weeks
ago,
I
said
idea
of
doing
ipld
with
replication,
so
I've
been
having
conversations
with
textile
team
to
figure
out
how
to
proceed
with
that
experiment,
and
I
think
we
want
to
move
the
ipfs
light
into
the
one
of
the
protocol
labs
organization.
I
I
think
I
was
suggested
to
do
the
ipfs
work,
but
I
need
to
figure
out
who
can
do
the
thing,
because
I
don't
think
I
have
a
privileges
myself
and
so
part
of
the
work
would
be
try
to
make
this
work
compatible
with
ipfs
lite
as
well,
so
it
can
work
with
either
itfs
sam.
The
next
one
is
improving
web
file
ad.
I
That
is
something
that
alex
took
over
and
landed
the
improvements
to
the
js
ipfs
and
I'm
going
to
update
the
web
ui
pull
request
that
I
have
there
to
take
advantage
of
those.
Obviously,
we
will
have
to
wait
for
ipfs
release
to
happen
before
we
can
pull
it
in,
but
I'll
update,
pull
request
to
just
pull
from
github
and
test
it.
That
way.
A
C
Yeah
yeah,
so
yes,
a
few
questions
and
and
one
comment,
the
comment
is
that
someone
in
hackfest
was
trying
to
basically
like
just
be
a
dht
server,
node
and
listen
in
on
content
that
they
hear
about
and
then
try
to
fetch
the
content
as
like
a
caching
mechanism,
but
because
go
ipfs
has
not
yet
done.
The
multi-hash
block
store
migration.
C
C
Is
it
on
the
roadmap
anywhere
for
js
ipfs
to
add
the
the
ips
over
pub
sub
like
persistence,
changes
that
made
it
into
ipfs
a
while
ago
or
is,
or
is
that
not
being
tracked
anywhere
yet.
C
Okay,
cool
yeah,
it
makes
sense.
It's
not
it's
not
a
huge
set
of
changes,
and
it
only
really
makes
a
difference.
If
there
are
it's
only
a
it's
only
a
bad
thing
that
it's
not
implemented.
If
there's
like
go
and
js
nodes
that
are
both
on
the
same
pub
sub
topic,
because
then
the
properties
are
like
unclear
because,
like
some
of
the
nodes
are
doing
one
thing
and
some
are
doing
another
thing:
okay-
and
I
think
that
oh,
I
guess
one
more
was
for
pinning
services.
C
I
saw
that
we
are.
We
would
like
to
do
the
mfs-based,
pinning
thing
where
you
know
when
you
update
your
mfs,
you
update
your
pins
at
the
pinning
service.
C
J
Yeah,
so
in
the
pinning
service
api
there's
an
update
and
operation
which
is
sort
of
like
a
porcelain
on
top
of
remove
old
one
and
create
totally
new
one
which
reuses
the
same
metadata
and
that's
effectively
what
will
happen?
We
leave
it
up
to
pinning
service
to
decide
when
to
garbage
collect
the
way
this
works
is
the
moment.
You
update
that.
Pin
that
all
you
you,
you
are
no
longer
guaranteed
that
the
old
pin
is
provided.
J
J
Yeah,
that's
that's
a
good
question,
so
the
billing
itself
is
not
a
part
of
the
spec
right
now,
there's
an
open
pr
to
add
a
creation
date
which
could
be
used
by
pinning
service
to
reason
or
like
create
some
like
building
logic.
But
it's
like
not
really
part
of
the
spec.
It's
not
like
when
you
pin
something
you
don't.
There
are
no
convention,
at
least
not
in
the
spec,
for
I
want
to
pin
this
for
a
week.
J
That
could
be
something
that
spinning
service
like
they.
Each
picking
service
could
have
their
own
logic
to
like
override
the
default
behavior.
But
the
assumption
is
that,
like
there
will
be
a
default
behavior,
which
user
assigns
to
the
api
token,
and
just
use
of
that
token
would
mean
you
won't
use
those
defaults.
C
J
J
C
K
I
have
a
quick
question
about
that
that
dht
stuff
is
there
like
a
good
reason?
Why
we're
not
putting
cds
in
the
dht
and
yeah.
C
K
Yes,
but
but
like
the
problem
that
we're,
I
mean
yes,
that
sucks
and
like
this
is
kind
of
a
legacy
of
cid
0
problem,
but
the
the
multi-hash
is
not
that
useful,
like
it's
the
difference
between
data
and
data
structures
and
if
we're
moving
to
a
model
in
which
we're
not
putting
every
single
block
into
the
dht
and
we're
just
putting
the
pins
in
then
those
multi-hashes
don't
really
mean
anything
like
they
just
say
like.
Oh,
I
have
this
block
for
this
root.
K
Node
you're
not
saying
I
have
this
graph
because
that
doesn't
mean
the
graph
like
you
need
the
actual
city
id
for
that.
There's
like
a
really
like
huge
drop
in
utility
by
shaving.
A
couple
bytes
off
of
this.
C
You're,
not
it's
not
shaving
bites.
It's!
It's
saving
many
network
round
trips.
So
if
we
end
up,
if
slash
one,
we
end
up
making
it.
So
you
know
you're
only
gonna
put
you
know,
maybe
only
the
root
nodes
into
the
dht
and
you're
going
to
put
them
in
not
as
these
like
sort
of
records,
where
you
just
say,
cid
data,
but
actually
like
a
signed
record
with
more
information,
then
yeah
we
can
put
cids
potentially
back
in
there.
C
K
Okay,
no
well!
This
is
only
for
the
case
when
you're
only
putting
the
pins
the
the
pin
roots
in
there
like
that's
because
then
you
know
you're
only
looking
at
a
dsp
to
establish
that
network
and
then
get
connected
to
a
few
you're,
not
like
doing
a
ton
of
other
lookups
in
the
dsg
for
every
block
down
the
graph.
So
we
wouldn't
worry
about
a
lot
of
round
trips.
In
that
case,.
K
K
K
Data
structures,
like
literally
like
it's,
the
difference
between
data
and
a
data
structure
because
like
if
I,
if
I
can
decode
it,
then
I
can
potentially
pull
out
links.
I
can
like
look
at
the
semantic
information
it.
It
actually
just
means
something
way
different
when
it's
a
cid
versus,
but
I
can
just
yeah
but.
K
No,
no,
you
can't
guess
like
that.
No,
no,
like
you're
you're,
you're
thinking,
you're
thinking,
cidv0,
everything
is
256.
like
shot
two
everything
with
eggpudy
but
like
in
in
like
all
of
the
the
new
stuff
that's
getting
about.
If
you're
textile,
if
you're
like
these
other
folks,
you
can't
just
get
like
you,
you
really
can't
all.
K
We
have
three
more
codecs
coming.
People
are
talking
about
more,
not
to
mention
like
ethereum
blocks
and
get
blocks,
and
we
just
took
all
of
the
bitcoin
blockchain
and
put
it
in
as
well
like
there's
a
lot
of
codex.
Like
you
really
don't
know,
I'm
telling
you,
like
you,
don't
know.
K
Sure,
like
that's
the
actual
problem
like
like
I
mean
if
you
look
across
filecoin
like
they
may,
like
one
forced
them
to
make
things
cids
against
some
people's
objections
when
it
for
a
lot
of
identifiers
in
order
to
have
a
lot
of
this
flexibility
in
the
future
and
not
just
kind
of
future
proofing,
but
just
like
having
the
representation
mean
something
a
little
bit
different
and
and
locking
that
in,
and
I
really
would
hate
to
see
like
all
of
our
use
of
the
dht
get
locked
out
of
that.
For
like
I.
K
I
really
I
understand
the
optimization
of
not
wanting
to
two
round
trips
while
we're
in
this
limbo
state
of
migrating
from
cidv0
like
that,
does
suck
but
like
if
you're
looking
to
the
future
at
all
like.
We
really
want
to
start
thinking
of
these
cids
wherever
possible
and
in
the
case
of
the
pins
like
like,
we
can
do
it
pretty
efficiently
without
worrying
about
the
performance
overhead.
I
agree
that
it
would
be
very
problematic
to
change
the
defaults
of
ipfs
to
broadcast
every
block
twice,
but.
K
Well
like,
if
you
look
at
the
primary
uses
of
dhts
other
than
us
and
other
than
protocol
labs,
like
the
the
hashes
that
get
put
into
the
dht,
have
an
agreed
upon
semantic
understanding
because
they
they
exist
in
the
name
space
so
like
when
you
look
something
up
in
the
bittorrent
dht
like
you
know
that
it's
going
to
be
an
infohash,
and
so
you
can.
You
can
create
the
data
structure
out
of
it
and
like
get
that
out
of
it.
We
don't
have
that
benefit
unless
it's
a
cid.
K
If
it's,
if
it's
just
a
multi-hash,
then
we're
just
talking
about
binary
data,
and
we
can't
really
like
gain
any
semantic
representation
out
of
it.
Unless
it's
a
cid,
I
mean
that's
like
that's
literally,
like
the
entire
kind
of
point
of
the
ideas.
K
A
We
are
over
time
yeah.
This
is
an
interesting
discussion,
though
I
think
we
should
take
this
to
a
github
issue
and
get
to
the
bottom
of
it.
What
is
data
anyway
to
someone
who
doesn't
know
what
they're
looking
at
cool?
So
thank
you
very
much
everyone.
This
has
been
the
ips
core
invitations.
Weekly
sync
for
the
27th
of
july
2020.,
see
you
next
week
stay
safe.