►
From YouTube: Go IPFS 2019-Q2 OKRs
Description
@eingenito gives an update on 2019-Q2 OKRs for the go-ipfs team.
https://docs.google.com/spreadsheets/d/1YSeyWqXh3ImanRrTkYQHHkCofiORn68bYqM_KTLBlsA/edit#gid=1720716278
https://github.com/ipfs/js-ipfs
A
Everyone
is
Eric
from
the
NGO
ipfs
working
group
and
I'm
gonna
be
going
over
our
cue
to
okay,
ours
in
the
spreadsheet
you
see
before
you
the
first
set
of
okay.
Ours
are
related
to
supporting
package
managers,
they're
kind
of
a
little
bit
obvious
because
they
all
have
to
do
with
speed
and
scalability
to
support
the
large
volumes
of
data
and
large
volumes
of
traffic
that
package
managers
or
the
project
managers
running
on
top
of
ipfs
are
going
to
need.
A
The
first
one
is
it's
possible
to
are
sync:
to
go:
ipfs,
there's
sort
of
two
initiatives,
adjacent
initiatives:
one
is
a
performant
writable
fuse
implementation
and
one
is
improved.
M
FS
and
dominic
is
on
point
for
this
one.
Next
one
is
continued
work
on
improve
provider
strategies.
There
are
a
number
of
different
options
for
provider
strategies
and
we're
going
to
need
to
basically
make
more
efficient
use
of
the
DHT
when
adding
and
providing
really
really
large
data
sets.
A
Third
one
is
when
connected
to
the
global
internet.
Ip
and
s.
Resolution
takes
less
than
a
second
there,
a
couple
of
initiatives
underway,
IP,
NS,
/,
DNS
improvements
and
then
IP,
NS,
/,
pub/sub
number
seven
is
go,
ipfs,
saturates,
I
assume
is
100
megabit
link
when
downloading
a
sufficiently
large
data
set
it's
important
when
you
need
to
be
able
to
transfer
a
lot
of
data
quickly
and
the
next
one
goes
right
hand
in
hand
with
it.
Go
ipfs
has
at
most
ten
percent
overhead
when
downloading
a
large
data
set.
A
We
don't
want
to
use
all
of
our
throughput
for
overhead,
so
we
want
bit
swap
to
be
efficient.
Obviously
we
have
to
send
control
information
and
make
requests
send
our
sets
of
wanted
blocks
to
our
peers.
But
we
want
to
make
efficient
use
of
the
bandwidth.
We
have
available,
number
nine
is
go
I,
P
FS
has
experimental
support
for
mod
x
and
other
metadata.
A
In
many
many
small
files,
this
I
think
is
related
primarily
to
work
that
magic
is
currently
doing
on
the
Block
store
and
the
use
of
badger
for
storing
data
and
ipfs
and
magic
has
submitted
a
couple
of
important
bugs
to
badger
recently
that
I
think
they're
fixing,
just
in
the
last
few
days
that
are
great
and
mean
that
badger
will
successfully
GC
and
hopefully
over
the
course
of
the
quarter.
Badger
will
magics
test.
A
battery
will
show
that
it's
reliable
and-
and
it
is
highly
performant
in
most
cases,
storage
for
ipfs.
A
The
second
set
of
okrs
section
two
are
around
supporting
IP
at
best,
camp
users
can
reliably
find
content
via
the
Gateway.
It's
important
that
the
eight
days
to
please
work
and
do
pretty
good
job
for
ipfs
camp
to
go
smoothly.
There's
lots
of
stuff
involved
in
this.
Some
has
to
do
with
go
ipfs
and
some
is
more
on
the
lid
p2p
side.
There's
actually
like
other
OTR
is
in
here
that
relate
to
this
one
great
one
workshop
ready
by
ipfs
camp.
That's
a
Stephan
thing.
A
A
A
The
second
one
is
maintain
a
curated
list
of
important
non
kr
tasks.
This
is
just
as
a
working
group.
We
realize
that
we
have
other
stuff
that
comes
up.
That's
not
in
our
kr.
We
have
a
place
for
KRS
we'll
get
to
that,
obviously,
when
github
issues,
but
we
need
another
thing
which
is
a
subset
of
all
our
issues
which
are
important
to
get
done
and
make
progress
on,
but
they
don't
roll
up
to
K
arse
initiatives
related
to
care
go
into
a
q2
milestone.
A
We
have
nine
hundred
and
thirteen
hundred
or
forty
open
issues
until
ipfs,
it's
daunting
for
new
developers
or
new
contributors
or
I.
Don't
I
think
they
just
get
scared
away,
so
there's
actually
a
lot
of
valuable
information
in
those
issues.
A
lot
of
very
few
of
them
are
just
sort
of
spurious
or
no
longer
applicable.
A
lot
of
them
are
good
feature
ideas,
but
we
have
to
figure
out
what
to
do
with
them
and
sort
of
get
them
out
of
the
main
go
ipfs
issues
set,
so
the
issues
become
useful
instead
of
just
daunting.
A
The
developers
who
are
working
on
go
ipfs
have
to
sort
of
have
various
ways
of
dealing
with
this,
but
for
people
coming
in
to
a
project-
and
you
probably
is
a
little
bit
crazy.
This
is
one
of
the
ways
we
deal
with.
It
started
using
a
special
flag
for
things
to
pick
up
and
interrupt
on.
We
realize
that
we
have
a
lot
of
issues
are
just
a
lot
of
issues.
Take
a
long
time
to
consider.
Some
of
them
are
really
like.
A
If,
if
someone
wants
it
done,
they're
gonna
have
to
do,
but
some
of
them
are
important
for
the
core
team
to
pick
up
on
immediately
and
we're
gonna
use
an
interrupt
label
and
talk
about
them
in
our
weekly
and
socialize
them
or
broadcast
them
in
our
IRC,
so
that
people
know
that
there's
new
things
that
have
come
up
and
though
this
last
one
in
this
section
is
a
creation
of
a
plan
for
moving,
go
ipfs
to
use,
go
I,
feel
to
be
prime
and
then
section.
Four
is
okay.
Ours
around
supporting
IPF
users.
A
So
we're
going
to
support
them
in
that
effort
and
then
audit
ipfs
api
secured.
It
is
something
that
kuba
is
undertaking.
I
think
he's
already
started
so
probably
the
last
quarter
in
this
quarter,
and
that
is
it.
If
you
have
any
questions,
don't
you
can
certainly
reach
out
to
me,
and
you
can
also
we
have
like
all
the
working
groups.
We
have
an
okay,
our
issue,
where
I
think
it's
a
PR
actually
linked
to
from
the
master
list,
that
you
can
go
and
check
out
and
add
comments
to
it'll
respond.
So
thanks
very
much.