►
A
Hi
everyone
welcome
to
the
ipfs
core
implementations
weekly
sync
for
monday,
the
30th
november.
I
am
akin
brain
I'll,
be
your
host
we're
going
to
go
through
our
hyper
initiatives.
Other
initiatives,
q,
a
parking
lot,
all
the
usual
stuff.
It's
going
to
be
awesome,
kicking
off
for
the
high
priority
initiatives
upcoming
and
ship
releases.
B
Yes,
the
ipfs
0.8
rc
is
is
near.
We're
like
we're
like
this
close
there's,
there's
a
couple
of
of
like
things
to
polish
up
on
the
painting,
services
and
local
pinning,
but
they're
everything
seems
to
be
passing,
and
so
it's
just
like
making
sure
we
have
like
a
final
final
review
of
nailing
down
all
the
interop
things
we
needed
to
interpret
to
nail
down,
but
yeah
we're
almost
there
we'll
cover
more
when
we
get
to
them
in
the
next
sections.
C
And
so
we
also
started
in
just
the
preparation
for
the
0.30
release.
I
seem
to
reject
last
week
and
we
decided,
since
we
already
have
so
much
to
release
that
it
didn't
make
that
much
sense
to
wait
for
the
rendezvous
to
be
done.
So
we
also
wanted
to
start
making
smaller
releases
from
now
on.
So
we'll
we
are
starting
to
prepare
to
do
the
rc.
Probably
this
week
for
just
a
bit
with
0.30,
I
already
started
integrating
with
jspfs
and
the
ci
is
green,
which
is
great
and
yeah.
D
D
It
should
do
the
same
thing
that
we
already
do
for
the
private
key.
That's
the
short
story
and
you
likely
created
a
mock
pinning
service,
which
is
much
lighter
than
running
entire
rails
up
in
with
docker
compose
on
the
ci.
So
we
may
want
to
switch
to
that
now
that
we
know
the
test
path
and
our
green,
we
may
switch
to
that.
D
So
we
don't
need
docker
based
infra
on
the
ci,
do
that
before
we
merge
it
to
master
mostly
to
ensure
the
ci
is
robust,
because
right
now,
even
though
we
check
out
the
specific
revision
of
the
ravion
rails,
pinning
service,
the
docker
compose
file
itself
uses
the
latest
tag
for
a
docker
image.
So
it
actually
does
not
pin
ci
to
specific
version,
and
it
may
break
any
at
any
point.
D
A
B
So
local
pinning
is
basically
done.
We've
we've
hammered
through
all
of
the
repo
migrations
stuff
before
we
have
to
go
back
and
like
rewrite
how
we
do
migrations
due
to
some
problems
that
we
noticed,
we
switched
things
over
we're
having
some
minor
issues
with
with
the
seabor
serialization
deserialization
stuff,
that's
fixed
now,
because
we're
using
atlases.
B
The
only
thing
that
I
I
noticed
today
as
I
was
double
checking
some
like
js
and
go
interop
stuff,
is
that
we
don't
use.
We
use
the
pin,
I
guess
depth
as
an
enum
instead
of
an
integer,
neither
go
nor
js,
actually
support
anything
other
than
direct
or
recursive
pins.
B
It's
like
something
we've
talked
about,
so
I
don't
know
if
this
is
like
and
and
the
remote
pinning
services
don't
do
this
either.
So
it
seems
like
we
might
be
fine,
just
leaving
it
as
an
enum,
but
I'm
open
to
changing
it.
Also,
if,
if
people
think
that
preparing
us
for
that
is
important,
I
also
noticed
that
I
I
couldn't
tell
whether
javascript
is
storing
their
data
store
in
dot,
pins
or
slash
pins.
B
Secio
has
been
the
old
dht
nodes
have
been
our
dht
booster
nodes
have
been
turned
off
and
the
new
ones
don't
support
secio,
so
the
nodes
that
are
still
on
the
network,
it's
still
connected
to
everybody
or
those
that
are
still
connected
to
people
in
the
public.
Dht
are
just
nodes
that
have
either
kind
of
hacked
around
things
or
they
just
haven't
turned
themselves
off
yet
and
restarted.
B
B
B
F
A
On
the
pending
thing,
for
the
record,
jsrpfs
does
support
arbitrary
depths.
It
just
doesn't
just
doesn't
expose
it
at
the
moment.
Hector
talked
me
into
thinking.
It
was
important
because
he's
you
know
it
was
for
the
cluster
use
case
of
saying.
Here's
a
dag
like
just
just
pin
this
bit
of
it,
and
then
this
one
can
pin
like
the
rest
of
it
or
whatever.
A
B
D
In
the
pinning
service
api
we
initially
had
depth
parameter,
but
we
like
removed
it,
and
it's
like
now,
it's
just
implicitly
recursive,
mostly
because
we
did
not
want
to
make
that
decision
in
that
third
party
api
before
we
make
a
decision
in
like
go
up
as
js
ipfs.
So
that's
the
only
reason
why
we
don't
have
like
the
type
of
pin
and
it's
just
implicit.
F
G
Exactly
what
they
are
do
we
have
a
use
case
for
for
depth,
pinning
depth.
A
The
cluster
was
one,
and
I
was
also
when
I
was
messing
around
with
npm
on
ipfs.
I
did
not
want
to
pin
all
of
npm.
B
Yeah,
I
mean
it's
still
it's
it.
The
use
case
is
a
little
funky
in
that
it
seems
like
what
you'd
prefer
is
to
give
people
like
a
particular
subtree
of
a
dag,
but
then
you
need,
and
then
you
need
a
way
to
describe
like
a
selector
for
like
the
first
path,
where
you
only
have
like
one
path
going
down
and
then
the
whole
tree.
But
in
lieu
of
that
you
could
do
depth
and
just
say:
I'm
just
gonna
go
like
you
know,
I'm
just
gonna
go
like
two
levels
down
yeah.
That's.
G
One
of
the
reasons
I'm
saying
is:
if
we're
going
to
do
something,
maybe
we
need
to
make
room
for
something,
that's
more,
maybe
more,
in
line
with
an
actual
use
case
like
having
the
ability
to
specify
a
selector
as
opposed
to
just
a
depth
yeah.
I
think.
F
B
H
B
Right
yeah,
I
mean
at
that
point
at
that
point.
I
feel
like
I'd
rather
just
leave
things
as
they
are
and
write
a
migration
later,
because
selectors
only
really
exist
in
go
ipld,
prime,
and
we
don't
really
have
that
anywhere
in
the
ipfs
code
base.
Yet
except
for
like
very
tangentially,
so
I
don't
want
to
go
down
that
so
I'm
trying
to
hold
right
now.
G
B
I
think
it's
making
it
more
convenient
for
in
in
like
a
cluster
sort
of
environment,
where
you
want
to
split
up
the
chunks
of
the
tree
among
people,
and
you
can
coordinate
all
of
that,
but
without
using
sort
of
direct
pins
for
like
every
single
node,
it's
just
being
like
allowing
that
to
be
managed
a
little
easier.
I'm
not
convinced
this
is
like
the
best
or
only
way,
I've.
I
So
this
the
thing
is
that
this
this
question
interferes
with
content
routing,
because
this
really
is
kind
of
like
a
content,
routing
type
strategy,
and
so
the
question
is:
should
people
think
of
the
of
the
content
trees
as
something
that
pertains
to
content
to
the
nature
of
content
and
where,
as
opposed
to
something
that
there
is
a
mechanism
for
partitioning
what
things
you
want
to
provide
and
not
like,
we
need.
I
You
know
dividing
up
the
three
between
different
people
and
so
forth.
I
mean
I'm
just.
J
I
B
My
thinking
is-
maybe
maybe
we
should
just
like
leave
things
as
they
are
punt
on
this,
so
we
can
do
a
migration
when
we
add
features,
but
also
I
wanna.
We
can
come
back
to
this
and
the
and
like
the
stuff
at
the
end,
but
I
don't
wanna
hold
up
the
rest
of
the
meeting
for
this.
So
let's,
let's
keep
going
and
we'll
we'll
see
how
time
goes.
A
Cool,
so
we
talked
about
circuit
removal.
Next
up
is
js,
improves,
discoverability
and
connectivity.
C
Yes,
so
the
the
websocket
was
now
updated
and
finally,
we
will
not
anywhere
in
the
browser
dial,
non-dns
websocket,
secure
multi-others.
So
all
those
annoying
warnings
that
people
complain
a
lot
will
finally
be
gone.
As
I
said
before,
I'm
working
now
on
the
real-life
production
guide
and
in
the
renewal
side
of
things.
I
started
working
on
it
in
the
beginning
of
last
week
and
I
basically
got
to
the
point
where
the
mysql
integration
database
model
and
the
queries
are
mostly
done.
C
A
Next
up
is
bi-directional
streaming
and
streaming
errors
in
the
browser,
so
this
is
the
same
as
it
was
last
week.
I
don't
think
I've
got
any
comments
on
that
pr
which
either
means
it's
perfect,
which
I
find
very
hard
to
believe,
or
just
no
one's
had
the
time
to
look
at
it.
If
people
could
please
cast
an
eye
over
it,
I
would
be
very
grateful.
A
So
in
the
interim
I
picked
up
the
dht
work.
We
were
trying
to
basically
implement
it
in
node.js.
Properly,
have
a
some
kind
of
reasonable
performance
guarantee
about
how
long
a
query
will
run
for
the
first
part
of
that
is,
I
think,
making
sure
you're
dialable,
because
what's
the
point
of
having
a
dht,
if
you're
not
dialable,
so
I
implemented
a
quick
network
manager
that
uses
upnp
to
do
hole
punching
through
your
router.
If
it
supports
it,
there's
a
pr
open.
A
If
people
could
look
at
that,
I'd
be
very
grateful
if
it's
also
the
direction
that
we
want
to
go.
B
I
mean
it
would
be
really
it's
still
quite
useful
if
you
have
if
the
dht
client
is
working,
just
fine
and
nobody's
dialable
and
nobody
is
ever
in
server
mode,
that's
probably
like
yeah.
I
know
at
least
for
me
that
seems
like
probably
the
like.
The
more
users
are
like
users
asking
for
this
kind
of
thing,
like
even
in
go.
B
We
see
like
there's
a
much
larger
number
of
client
nodes
than
server
nodes,
so
yeah,
just
as
a
heads
up
like
if
you
you
start
having
to
worry
about
like
autonat
and
any
of
the
other
like
servery
things
like
you
could
just
say
like
screw,
it
we're
gonna,
do
client
mode.
E
A
Okay,
that
is
the
end
of
the
high
priority
initiatives.
Moving
on
to
other
initiatives,
so
far
add
process
in
the
web
ui.
H
That's
me:
it's
on
a
back
burner,
while
I'm
working
on
the
remote
cleaning
stuff
so
update
there
this
week.
I
have
something
on
the
next
item
too,
which
is
typescript
integration
for
ipfs.
H
H
I
update
the
pull
request
for
ipfs
speed,
swap
after
hugo
got
around
to
review
it.
I
think
I
might
have
to
do
another
pass
on
it.
Then
there
is
a
pull
request
about
removing
api
manager,
which
makes
typing
of
ipfs
a
lot
more
easier
alex.
If
you
can
review
that,
that
would
be
great,
then
I'll
review
your
patch.
A
H
Oh
yeah
hugo,
can
we
release
that
because
I
don't
really
see
if
there's
any
reason
not
to
release
it?
It
doesn't
depends
on
the
changes
here,
so
that
would
make
it
a
lot
easier
for
me
to
also
keep
merging
updates
into
it
and
what
is
the
last
one?
Oh
yeah,
and
then
I
discovered
the
regression
in
our
typing
stuff,
after
which
timeout
options
have
move,
has
moved.
H
H
That's
what
I
my
end
on
typescript.
I
think
hugo
has
more
updates
here.
K
Yep,
okay,
so
yeah
the
bit
swap
stuff
is
already
talked
about.
We
have
prs
for
the
interface
data
store,
the
data
store
core
and
multi-other
the
multi-other
one
is
gonna.
K
Apparently
I
think
we
agree
that
we're
gonna
do
a
breaking
change
because,
like
exporting
the
function
that
creates
a
class
like
in
the
old
javascript
way,
it's
hard
to
for
typescript
to
understand
that
so
just
exporting
the
class
it's
much
better,
but
it's
a
big
breaking
change
for
the
users.
We're
gonna
try
to
make
it
a
little
bit
easier,
but
I
think
we're
going
to
do
it.
K
There's
a
touchscreen
bug
reported
that
has
been
marked
as
a
bug
and
scheduled
for
4.2.
So
that's
super
good
for
us.
It's
gonna
unblock
a
lot
of
easier
typing
with
jstocs
and
also
the
next
version
of
type
talk
looks
to
work
much
much
better,
with
common
gs
and
js
stock
types
or
common
gs
sources
with
jsoc
types.
C
And
in
the
the
lipid
pit
site,
I
updated
the
my
pr
to
use
the
new
idea,
the
tool
released
last
week,
and
now
I
also
can
use
the
type
check
script.
C
We
had
more
than
400
errors
on
types
I
fixed
more
most
of
them,
but
now
I
need
to
go
to
the
interface
to
unblock
the
rest,
because
we
we
have
things
like
the
transport
and
the
mixer,
and
then
we
access
methods
from
there
and
we
don't
have
declarations
for
them.
So
basically,
I
will
need
to
first
create
a
type
declaration
for
each
interface
and
then
I
will
be
able
to
finish
the
delete
vpr
and
that's
it.
H
There's
actually
one
thing
that
might
be
worth
considering:
one
thing
I'm
trying
to
do
is
things
that
are
interfaces
between
components
to
define
them
as
interfaces
like
datastore
and
few
other
things
for
transport.
It
might
make
some
sense
make
sense
there
too,
so
we
code
against
the
interface
rather
than
against
our
own
implementations.
That
depends
on
like
internal
quirks,
because
then
you
can
see.
If
interface
is
incompleted
and
has
things,
then
we
should
like
you,
trade
on
the
interface
to
improve
it
rather
than
just
find
the
backdoors.
C
Yeah,
we
I'm
doing
also
with
the
interface
because,
from
the
elliptic
perspective,
you
basically,
for
example,
to
the
transport
manager
you
provide
transports,
but
then
in
inside
the
transport
manager.
It's
like
everything
is
a
transport
and
not
like
web
sockets
or
tcp.
So
you
need
to
have
the
interface
so
that
you
can
use
and
have
the
types
generically.
H
Yeah,
so
I
I
think
it
would
be
interesting
to
decide
where
do
we
keep
those
interface
files,
because
right
now,
I
kind
of
have
a
few
that
I
in
the
pull
request
in
the
ipfs
repo,
but
they
don't
really
belong
there.
So
maybe
we
need
some
package
that
has
like
interface,
stuff.
C
H
Yeah,
I
did
another
pass
of
updating,
pull
requests
to
address
three
view
comments.
I'm
not
sure.
If
did
you,
I
don't
know,
I
have
to
look
if
it
got
any
review
yet.
A
For
the
the
example,
it's
merged
yay,
okay,
so
it's
done.
A
Right
baja
2
support.
G
Right,
the
only
thing
that
I've
done
is
removed
the
there's
some
profile,
a
badger,
2
profile,
information
that
was
merged
a
while
ago,
removed
that
so
that
we
don't
have
any
reference
to
badger
2
and
so,
but
they
haven't
moved
just
checked
this
morning.
A
G
Some
prototyping
work,
but
no
nothing
to
report
yet
design
pending
very
soon
as
it's
been
for
a
while.
So
but
no
they
did
some
prototyping
work,
which
revealed
a
couple
of
other
things
which
I'll
discuss
with
those
who
those
who
will
be
concerned
with
it
anyway,
yeah
nothing,
nothing
to
report
there
than
that.
A
Cool
into
the
other
stuff
design
review
proposals,
please
have
a
look
at
my
bi-directional
streaming
pr
blockers
and
asks
questions.
H
Parking
lot,
oh,
I
had
a
ask
sorry:
can
we
create
those
meeting
notes
like
after
this
meeting
for
the
next
week?
So
as
I'm
making
things,
I
could
add
nodes
there
rather
than
having
a
like
temporary
buffer
and
then
kind
of
trying
to
put
them
in
right
before
meeting.
I
think
it
would
be
very
helpful
if
we
did
so.
A
B
I
guess
I
haven't
asked
about
the
parking
lot,
which
is
that
eric
the
link
isn't
isn't
public,
which
I
don't
know.
If
that's
intentional
or
not,.
L
Oh
great,
no,
I
don't
use
google
docs
very
much,
and
so,
when
I
do,
I
have
frankly
no
idea
what
I'm
doing,
especially
with
access
control,
so
I'll
figure
out
how
to
fix
that
later.
But
there's
a
link
there
that
you,
some
people
should
be
able
to
see-
and
everyone
will
see
later
once
I
fix
it-
of
the
ipld
team-
is
figuring
out
what
our
priorities
should
be
for
the
coming
year
and
trying
to
take
some
notes
in
advance
on
that.
L
So
some
of
that
might
be
of
interest
to
folks
here.
Some
of
it
might
not
it's
probably
at
least
a
little
relevant,
especially
for
anyone
who's
going
to
be
thinking
about
how
we
integrate
the
latest
ipl
code
bases
into,
I
think,
especially
go
ipfs
is
looking
forward
to
some
renovations
there.
L
L
H
L
E
Also
hannah
and
alex
creekshank
will
be
back
on
next
week,
so
we
can
sync
up
with
them
as
well
and
figure
out
everything
we
need
to
do
to
get
go
ipl,
prime.
All
up
in
go
ipfs.
H
I
have
one
other
thing
that
I
want
to
point
out
so
unrelated
to
this
subject.
As
I've
been
working
a
little
bit
more
on
the
remote
pinning
stuff,
I
did
find
certain
api
things
little
awkward
and
I
was
wondering,
and
then
I
talked
to
lydle
and
it
seems
that
decisions
were
intentional
and
the
goal
is
to
fix
them
later
on
and
I'm
going
to
propose
it's
good
to
have
a
document
where
we
say
this
is
where
we
want
to
be
and
how
we
want
to
be.
H
But
we
decided
to
do
this
now
for
now.
So
it's
easy
to
share
with
everyone
involved
to
be
able
to
see
where
it's
going
and
what
the
end
goal
is.
B
Yeah
yeah,
so
we
have
a
hack
md,
where
we
tried
to
basically
from
the
go
ipfs
when
js
ipfs
like
what
what
we
want,
the
sort
of
the
the
ipfs
apis.
To
look
like
that.
Allow
us
to
do
this.
I
suspect
that
I'm
not
sure
exactly
like
which
points
you're
getting
at
or
whether
it's
the
things
like
we
don't.
You
know
not
authenticating,
using
like
lupita
p
streams
or
whether
it's
things
like
or
having
acls
for
groups
of
pins
or
whether
it's
things
like.
H
So
two
things
that
are,
I
found
a
little
awkward,
was
first
of
all,
having
this
remote
and
local
namespace.
I
think
what
I
would
feel
more,
naturally
using
pinning
service
is,
say,
ipfs,
pin
and
specify
target
wear,
and
it
could
be
local
and
few
other
services
that
I
named
or
like
something
along
those
lines.
Rather
than
having
to
procedurally
go
and
like
pin
every
place
I
wanted
to
another
one
was
the
request
id.
B
H
G
H
I
So
you
you,
you,
here's
the
issue
so
you're,
suggesting
that
you
want
first
of
all
you're,
making
an
assumption
that
yeah
these
pins
should
be
have
different
stuff
in
them,
which
is
a
sort
of
a
quoted
assumption.
I
guess.
But,
but
are
you
suggesting
that,
like
the
pin
id
should
be
some
kind
of
a
hash
of
all
the
things
cids
that
are
in
it.
H
Yeah,
so
we
do
have
a
pin
object
right.
Well,
not
really,
but
we
kind
of
pretend
so
that
we
have
pin
objects
that
has
metadata
and
much
of
other
things
and
actually
linked
to
the
cid.
So
what
I'm
saying,
maybe
is
that
pin
should
not
be
identified
by
the
request
id
that
somebody
generates
but
should
be
identified
by
the
hash
of
that
thing,
and
if
you
want
to
pin
the
same
thing
same
like
dog,
with
two
different
pins,
well
make
something
different
about
it.
That's
up
to
you
sort
of.
I
Random
number,
so
here's
the
problem,
yeah
the
problem
is
race
conditions,
because
you
have
asynchronous
access
to
the
pinning
service
and
if
you
say
something
like
remove
my
pin
it's
kind
of
like
I
guess
it
becomes
an
item
button,
so
we're.
B
F
E
So
I
agree
there
is
a
a
roll
up
of
all
this
information
that
we
should
at
least
try
to
do
like
gather
the
summary
of
this,
especially
like
before
we
wrap
up
for
this
year,
so
that
we,
you
know
people
don't
go
on
holiday
and
then
come
back
and
totally
forget
what
we're
doing
where
we
create
this
thought
stream
of
hey.
We
had
the
pinning
meet
up
earlier
this
year,
lydell
created
the
dock
for
the
work
streams.
E
We
created
some
subsequent
hack
md's
for,
like
those
various
things,
let's
roll
up
the
thoughts
on
like
okay,
when
we
come
back
to
revisit
this,
especially
like
looking
at
improving
content.
Routing
early
next
year,
where
should
pinning
go
in
the
long
term
to
have
those
conversations
so
that
we
can
then
write
out
the
thoughtful
thing
with
getting
this
thing
working
for
now,
so
that
we
can
migrate
over
to
the
the
better
well
thought
out
thing
in
the
future.
Yeah.
H
B
Also
is,
I
guess,
like
a
brief
heads
up
on
things
related
to
the
ipfs
api,
we
have
a
very
difficult
time,
at
least
in
go
but
like
updating,
updating
the
apis
without
breaking
everyone's
flows.
So
we
have
some.
We
have
like
a
couple
proposals
in
place
for
like
how
we
might
tackle
this,
but
that's
sort
of
the
reason
things
look.
A
little
awkward
is
because
of
doing
gradual
development
without
making
everything
break,
and
we
need
to
make
our
upgrade
pads
easier.
But
that's
like
that's
another
thing
on
the
roadmap.
A
We
are
way
over
time.
I
think
we
should
call
this
to
a
close.
Thank
you
for
coming.
Everyone.
Do
please,
put
your
async
updates
in
the
notes.
Let
us
know
what
you've
been
working
on
where
you're
blocked
on
what
are
you
doing
next,
it's
gonna
be
like
everyone
wants
to
know.
Let's
talk
about
this
stuff
cool.
Thank
you
very
much
everyone.
This
has
been
the
ibf's
core
implementations
weekly
sync
for
monday,
the
30th
november
I'll
see
you
all
next
week,
bye.