►
From YouTube: Q4 2018 libp2p OKR Meeting
Description
Short meeting with go-libp2p, js-libp2p and rust-libp2p participants to discuss OKRs for Q4.
Direct your follow up discussion to:
- JS: https://github.com/libp2p/js-libp2p/pull/247
- Go: https://github.com/libp2p/go-libp2p/pull/425
- Overall project: https://github.com/libp2p/libp2p/issues/50
Work-in-progress (as of 9/20/18) Q4 OKR doc is here: https://docs.google.com/spreadsheets/d/1BYwmbVicgo6_tOHAbgiUXWge8Ej0qR1M_gAUulazmrg/edit
A
So
I'm
up
to
number
4,
which
is
a
product
goal,
get
getting
more
down
streams
and
then
number
5
is
I
kind
of
broadly
call
it
like
the
marketing
goal
that
basically
this
came
out
of
I
had
one
and
I
had
a
discussion
in
the
last
quarter
about
how
some
of
the
events
that
we
were
hosting
like
lab
day
and
the
D
Web
Summit.
They
took
a
lot
of
time,
but
they
weren't
would
ever
reflected
in
the
okay,
ours
and,
and
so
his
thought
was
that's
probably
a
bug
in
the
okay
ours.
A
So
I
want
to
try
to
budget
time
for
that.
This
quarter,
so
I
just
have
basically
two
categories.
Well,
I,
so
have
us
I
have
several
events
that
we
should
just
assume
like
they'll
be
some
situation
will
arise
where
we
need
to
do
another
lab
day
or
need
to
use
the
wrong
way,
but
it
we
have
it
an
opportunity
to
do
another
lab
day
and
we
think
it
would
benefit
the
project
and
I
have
some
goals
around
the
team
week.
A
And
I
have
some
goals
around
this
is
I.
Can
I'll
take
this
one
I
think
Michael
needs
some
help,
planning
I
forget
what
he's
calling
it
right
now,
but
it's
like
ipfs
week.
It's
something
that's
going
to
happen
in
in
the
spring
of
next
year,
but
I
don't
know
quite
what
he
needs,
but
I
figure
all
right.
Let's
try
to
give
him
some
support.
There'll
be
one
lit
PP
day.
Then
the
rest
of
our
documentation
goal
is
like.
We
really
need
to
do
something
about
dogs,
so
the
whole
thing's
such
a
disaster.
A
It's
really
hard
for
anyone
to
understand
how
this
system
works
or
even
how
to
use
it,
and
we
have
a
lot
of
content
like
examples,
but
we
it's
not
there's
no
entry
point
to
them
and
so
I
don't
know
we
need
to
do
something
on
this
I'm
figured
out
how
they're
going
to
handle
it
anyway.
So
those
are
the
five
goals
at
the
project
level.
A
B
Documentation
I
think
that
documentation
is
in
the
marketing
section,
is
already
a
symptom
of
how
we
treat
documentation
and
if
we
want
good
documentation
needs
to
be
a
first-class
citizen
of
our
processes
and
how
we
work
on
this
stuff
and
so
should
probably
be
up
there
in
quality
and
dependability
and
should
maybe
think
about
something
like
if
there's
a
new
feature
and
it's
not
properly
documented.
Then
it's
not
ready
to
ship
yeah.
B
A
I
find
that
to
be
a
pretty
convincing
argument,
I
think
you're
right
I
think
we
need
to
give
some
basic
framework
for
where
to
put
your
documentation
for
different
types
of
things
and
then
I'm
far
better
I'm
fine
moving
an
engine
number
two
I
think
that
I
actually
think
it's
a
good
idea
is
I.
Do
think
it's
a
huge
quality
issue.
D
A
E
So
I
completely
agree
with
the
sentiment,
and
particularly
there
are
many
types
of
many
kinds
of
documentation,
which
is
why
I
think
we
to
make
it
an
objective
to
create
structure
around
the
documentation
right
because
it
could
mean
it
could
mean
different
things
to
to
everybody
or
change
this
or
participating.
So
I
think
we
need
some
kind
of.
E
We
need
definitely
to
keep
the
specs
up-to-date,
we
kind
of
user
manual
in
some
way,
like
it's
hard
to
define
user
manual
in
a
framework
that
is
so
deep
in
the
stack
right,
but
some
user
oriented
need
documentation.
We
need
to
make
sure
that
you
know
code
is
as
well
properly
documented
get
some
standards.
If
it's
possible-
and
you
know
some
sort
of
like
requirements
there
even
could
actually
have
my
github
bots
that
check,
for
you
know
levels
of
documentation,
whatever
a
PR
isn't
it
I
can
maybe
automate
some
of
this
process.
E
Maybe
have
a
checklist
about
that.
You
know
push
us
a
checklist
from
every
PR
that
the
submitter
needs
to
check,
to
make
sure
that
you
know
that
this
PR
needs
to
update
the
specs
that
that's
done.
The
needs
to
update
the
user
that
it
was
done
and
so
on
something
that
brings
you
to
a
bit
more
conscious.
You
know
effort
when
it
comes
to
code
versus
how
code
goes
together
with
documentation.
B
Yeah
one
very
easy
way
to
get
started
is
to
just
take
the
ipfs
documentation
website
and
duplicate
it
doc.
Sadly,
Piter
Piter
tayo
even
has
build
automation,
so
whenever
you
make
a
pull
request
or
push
to
master,
it
gets
rendered
an
editor,
ipfs
and
dns
gets
updated
and,
and
you
have
something
to
start
from
yeah,
it
even
pulls
in
API
documentation
for
Jas
and
Co
packages.
Oh.
A
I
see
yeah,
oh
I
think
this
is
a
really
good
idea.
I
mean
just
to
duplicate
this
structure
and
then
I
see
okay.
So
when
you,
when
you
open
a
PR
like
to
make
a
code
change
or
something,
then
what
do
you
open
us,
corresponding
PR
and
Docs?
Or
it
somehow,
you
just
add
docs
as
part
of
your
initial
PR?
Where
is
this
fed
from
it.
A
E
I
think
it
goes
under
quality,
as
we
would
have
suggested
today
in
conversations
on
the
interior
foundation.
Those
very
same
topic
came
up
and
they
are
having
a
region.
They
want
to
use
the
deeper
they're
having
a
very
hard
time
wrapping
my
head
around
some
of
the
concepts
so
and
maybe
to
fall
back
into
into
code.
Every
time
I
write
it.
This
creates
kind
of
like
a
vicious
cycle,
because
there's
no
feedback
was
that
a
commutation
is
crappy.
E
A
Whenever
I
talk
to
users,
this
is
the
number
one
thing
like
literally
everybody
who
tries
to
use
loopy
to
pee.
Even
people
who
are
using
it
successfully
mentioned
this
and
I
also
know
the
Russ
team
like
this.
They
tried
to
implement
from
the
specs
repo,
but
it's
an
it's
not
detailed
enough,
so
they
ended
up
using
like
the
go
code,
is
de-facto
like
a
defect
aspect.
A
A
E
B
B
A
A
My
worry
is
like.
If
people
want
to
find
out
about
lit
p2p,
they
they're
gonna
go
to
lip
pio,
pio
and
they're
gonna.
Look
for
a
link,
that's
like
docks
or
how
to's
or
something
like
that,
but
we
don't
have
to
put
the
full
content
on
that
side.
I
just
think
we
should
give
them
some
kind
of
trail
to
follow.
Yeah.
B
Yeah
definitely
the
thinking
there
in
the
beginning
was
just
that
all
our
project
website
seemed
to
be
very
focused
about
I'm,
just
giving
a
great
first
impression
of
the
thing,
but
not
very
geared
towards
well
educating
people
and
being
good
for
a
text
content
and
on
earth.
So
there's
a
lot
of
pointless
animations
and
oh
man
and
yeah
just
to
two
different
two
different
types
of
what
you
want
to
achieve
with
website.
Yeah.
A
E
A
A
A
Yeah
I,
while
we're
on
this
topic,
do
you
all
think
that
we
should
attempt
to
hire
someone
to
write
like
let's
say,
money's,
no
object
or
whatever?
Does
it
make
more
sense
to
hire
someone
to
try
to
write
Docs
for
all
the
stuff?
We
don't
have
documentation
for
now
or
do
you
think
that
a
higher
quality
Docs
will
come
with
engineers
themselves?
Yes,
Steven.
C
So
for
expectant
stuff
like
that
I
think
you'll
be
better.
We
write
them
because
they
tend
to
be
fairly
technical
and
actually
getting
other
people
to
like
get
to
the
point
where
they
understand
them
will
take
more
time
than
just
ready
to
myselves,
especially
if
we're
just
really
like
bicycling,
it's
very
minimal
like
hey.
C
This
is
how
this
works,
and
once
again
polish
we
come
in
higher
pitch
to
come
in
after
the
fact
like
book
with
these
basic
specs
like
rewrite
them
and
make
them
nice,
but
I
think
it's
we
just
like
say
it
looked
like
you
over
here
like
right,
there's
enough
people,
we
all
just
volunteer
for
different
sects
and
say,
like
oh
I'll
write
this
I'm
reading
works
all
right.
A
probably
DFC
works
whatever
and
then
just
get
something
down.
Severson.
F
Yes,
I
think
the
like:
we've
actually
gotten
in
the
dhananjaya
side
of
things,
we've
gotten
a
few
requests
lately
for
like
how
does
this
module
work?
How
does
this
integrate
with
Lib
p2p,
so
I
think
as
Steven
kind
of
mentioned,
the
even
the
intro
stuff
for
Limpy
to
be
is
like
it's
a
steep
learning
curve
unless
you're
familiar
with
it
already
and
so
making
sure
that
we
at
least
have
that
baseline
in
place.
So
then
somebody
could
come
in
after
that
and
then
enhance
documentation
from
there
and
clarify
things.
A
Yeah
yeah
actually
I
think
that's
a
really
good
idea,
because
it
would
be
a
fun.
It
could
potentially
be
like
a
fun
kind
of
group
activity
and
also
everyone
involved
would
be
able
to
see
like
if
we
wipe
ordered
out
exactly
how
the
DHT
works.
And
then
people
could
ask
questions
in
real
time
and
then
yeah
I
think.
C
It'd
be
activators,
have
everyone's
there
like
do
their
own
subsystem,
so
they
can't
shoot
right
now,
most
agree
of
everyone
working
same
thing.
You
can't
end
up
with
a
whiteboard
but
no
actual,
like
text
written
so
a
better
like
if
we
have
ever
like
sit
down
and
write
and
then
ask
each
other
questions.
Is
that
make
sense,
but
that
may
not
be
the
best
I'd.
Do
it
I
don't
know,
but
like
either
sinks,
let
alone
or
in
pairs
I,
don't
know
it's
like
doing
it
as
a
group,
business
or
I
would
do
it.
Yeah.
A
A
C
A
A
A
C
C
Present
to
each
other,
I
just
want
to
make
sure
that,
like
the
the
goal
of
that
session
would
be
writing
down
like
a
thorough
description,
even
if
it's
not
like
well
written
at
all
or
easy
to
follow.
If
it
comes,
it's
thorough
includes
all
the
information
or
well
enough
information
for
something
to
start
implementing.
It
then
I
think
that's
good,
but
yeah.
E
So
I
don't
want
to
say
in
previous
companies
we
did
have
a
technical
writer
and
the
documentation
on
quote
from
a
technical
writer
and
the
fact
that
you
know
they
are
so
someone
abstracted
away
from
the
project
and
the
subscribe
to
that.
There's
really
no
idea
when
they
come
into
the
project.
Really,
you
know
it
helps
like
it's
a
different.
It's
a
different
level
of
presentation
right,
because
if
we
write
documentation
ourselves,
we
all
have
some
level
of
knowledge
and
we
make
assumptions
right
so
they
are
oriented
to
them.
A
Yeah,
that's
what
I've
also
experienced
into
these
companies
so
now
I'm,
trying
to
think
cuz.
There
is
something
to
be
suffered.
They
come
in
and
ask
all
the
obvious
questions
that
that
the
people
who
are
gonna
write
this
stuff
won't
think
of
I
mean
because
it's
odd
sorry,
the
questions
that
are
all
things
that
are
obvious
to
engineers
won't
won't
get
written
the
things
that
a
fresh
pair
of
eyes
will
see.
Do
you
get
and
but.
C
E
Absolutely
that's!
That's
what
I'm
I
think
I
think
it's
actually
within
nine
years
that
DP
new
current
behavior
of
the
system
right
and
when
it
comes
to
translating
those
facts
into
like
actual
user
intelligence,
Owen
I
think
that
would
be
great
because,
like
channel
it
for
people
who
have
no
idea
what
they
see
in
the
first
place,
okay,.
A
G
A
A
A
Okay,
so
I'll
take
that
I'll.
Take
that
I'll
take
that,
as
these
goals
seem
basically
plausible,
as
sq4
goals.
A
lot
of
them
were
carried
over
from
q3,
so
I
think
we're
pretty
like
I.
Just
I
did
I
didn't
add
a
lot
of
new
stuff,
but
mostly
the
new
stuff.
I
added
was
dogs
and
the
etherium
2.0,
and
this
event
stuff
that
Juan
felch,
probably
should
have
been
in
q3.
So
now
let
me
pose
a
question.
The
group.
How
do
we
want
to
do
the
go
Jas
and
rust?
C
A
What
I
think
you're
advocating
for
is
a
Singh
I
in
general
I'm,
a
fan
of
async
but
I
feel
like
in
the
previous
okay
are
across.
Like
the
last
time.
We
did.
This
I
feel
like
it
didn't
work
like
people
just
didn't,
really
engage,
and
then
we
forced
everyone
to
sit
in
the
same
room
at
a
table
in
Berlin
and
only
then
were
people
willing
to
like
really
engage
on
it.
This
is
an
ensign
term.
I
can
sign
yeah,
go
ahead,
Jake,
it.
F
F
We
look
at
that
and
we
write
up
what
are
the
things
that
we
individually
think
need
to
be
done,
not
that
we're
going
to
do
ourselves,
but
that
we
think
need
to
get
done
for
it,
and
then
we
can
have
that
discussion
of
who
should
be
working
on
what?
How
much
can
we
actually
buy
it
off
and
we
turn
that
into
the
okay
ours.
F
One
thing
that
I
think
would
be
great
that
if
we
had
these
four
go
and
rust
and
were
able
to
have
those
conversations
that
we
could
denser
across
collaborating
of
are
there
dependencies
that
we
need
on
one
for
the
other
like?
Is
there
something
we
need
to
get
done?
We
know
in
j/s,
one
of
the
big
things
is
like
we'd
like
to
get
NAT
traversal
going,
but
the
spec
isn't
quite
there.
A
Yeah
that
makes
a
lot
of
sense
in
general.
I
think
it
well.
I
only
have
one
quarter
worth
of
data,
but
it
seems
to
me
that
Jas
has
consistently
means
when
quarter
done.
The
best
job
like
been
the
most
organized
about
this,
like
doing
it
on
time
scoring
on
time
and
stuff.
So
it
seems,
like
you,
guys,
have
a
good
process
with
the
go
team.
I
don't
know,
maybe
it's
just
because
it's
smaller
I'm,
not
sure,
but
it
seems
like
this.
A
E
So
writing
the
department
stores
for
that
so
that
it
gets
to
discussion
going
I
think
we
should
approach
it
in
the
same
manner
and
go
I'm
gonna
be
to
be
completely
up
for
this
I
think
the
discussion
is
very
constructive.
What
I'm
a
bit
worried
about
is
that,
at
the
end
of
the
day
these
for
the
projects
I've
had
the
coverage
any
good,
because
we
aren't
discussing
or
lowing
little
violence.
E
So
one
of
the
things
that
I've
set
up
for
for
myself,
I
do
know
or
people
think
about
this-
is
to
sort
of
like
in
this
water
do
so
right
now
in
the
website,
we
have
a
number.
We
have
a
list
of
all
the
modules
we
have
matrices
for
all
the
modules
across
the
different
implementations,
but
I
would
like
to
do
a
feature
drill
down
as
well.
E
So
we
could
take
decisions,
and
this
was
sort
of
like
feed
back
into
the
specs
work
as
well,
because
I
guess
this
Bank
it's
gonna,
be
for
each
of
these
modules
is
going
to
be
not
a
common
baseline
or
for
the
supportive
features,
or
maybe
we
realize
that
we
want
a
feature
that
is
only
present
in
one
particular
implementation
to
be
part
of
us
back
there
for
the
other
implementations
that
do
not
implement
it
will
need
to.
We
need
to
never
look
to
that.
I,
don't
know
what
what
do
you
guys
think.
A
E
Yeah
right
so
yeah
is
that
okay,
so
the
thing
I
would
like
like.
Ideally,
we
would
get
a
bit
deeper
and
go
down
to
the
feature
level
for
each
of
these
things
because,
of
course
like
implementing,
let's
say
the
sway
tournament,
a
UPnP
it
could
like
it
could
have
different
characteristics
in
each
of
the
implementations
that
could
be
different,
smaller
features
that
are
supported.
Maybe
time
outs
angry,
but
something
related
with
AI
abilities
for
things
like
you
know,
in
terms
of
threading
or
whatever.
A
A
Then
the
second
thing
is
what
Rose
is
getting
at,
which
is
granularity
like
do
we
want
to
take,
you
know,
take
something
like
switch
and-
and
you
know,
I
don't
know,
have
some
sub
rows
or
whatever
that
talk
about
specific
features
of
the
switch
and
whether
they're
implemented
in
the
different
languages
or
not,
and
but
so
this
is
what
this
is.
What
we
have
now
is
just
a
start:
it's
not
it's
not
where
it
needs
to
be
other
thoughts.
If.
H
F
F
H
Ian's
table,
but
yes,
if
you
can
hear
me
just
what
I
wanted
is
on
the
left
side,
we
would
be
fine
for
updating
this
kind
of
documentation,
but
don't
know
where
it
is
I,
don't
know
it's
like
someone
should
come
to
us
and
ask
us
to
date.
List
provide
a
link
to
it
or
I
have
I,
don't
know
exactly,
but
we
don't
know
what
to
do
if
we
need
to
update
documentation.
H
A
That's
my
fault.
Basically
I
haven't
put
a
lot
of
time
into
this,
but
my
plan
had
been
to
open
an
issue
in
Rustler
p2p,
just
being
like
hey.
Can
you
bring
this
up
to
date
so
for
now,
I
just
went
but
but
I'm
not
convinced
that
this
structuring
is
the
right
way
to
do
it.
So
I
didn't
want
to
waste
your
time.
I
I'm
not
trying
to
make
Russ
look
bad
or
something,
but
I
didn't
want
to
waste
your
time.
Yet
until
we
have
a
structure,
we
feel
better.
That.
A
C
E
So
the
thing
that
I'm
thinking
about
maybe
is
so
it's
a
bit
difficult
to
express
and
where
is
one
I'm
thinking
about
I
think
it
would
be
easier
to
just
do
it,
maybe
for
one
particular
module
to
do
the
cross-examination.
For
let's
say
the
connection
manager,
for
example,
which
we
know
has
differences
between,
go
and
then
p2p,
because
we've
seen
them
right
and
so
then
I
do
like
drill
down
into
the
connection
manager
and
spot
out
what
the
differences
are,
though
the
features
are
and
how
they
are
implemented
across.
E
A
Yeah
I
I
think
that
would
help
I
talk
to
you
about
this
idea
in
the
past
and
I
sort
of
I
think
I
understand
what
you're
saying
but
I.
Don't
I
don't
have
a
complete
picture,
and
so
maybe
other
people
are
in
the
same
limo
tonight.
Yeah
I.
Think
if
you
did
it
for
just
one
module,
might
it
might
help
a
little
bit.
A
Okay,
hey
so
to
just
to
bring
this
back
to
the
oak
arrow
discussion.
So
is
the
consensus
here
that
Jas
go
well?
Okay,
I'll
just
say
the
ID
I,
like
best
I,
think
Rose,
the
one
who
proposed
it
that
go
should
open
an
issue
in
parallel,
like
basically
the
same
as
that
Jas
issue
of
what
people
want
to
do
this
quarter
and
there
can
be
discussion
in
there
as
there
is
in
the
JSU
and
then
that
would
eventually
flow
into
this
document.
A
A
H
A
H
Yeah
I
mean
I
understand.
Do
you
mean
if
you
want
to
bring
more
people
project?
Okay,
it's
so
much
easier
to
just
say:
hey
what
you
think
about
that.
We
should
do
this.
We
should
do
that,
but
like
going
to
group
treats
and
everything
I
know
so
I
already
talked
about
this
in
previous
meetings
like
right
now
we
realize,
but
when
is
budgeted
for
substrate
a
bit
different
from
way
we
design
recipe
twist,
so
we've
been
with,
indeed
this,
so
the
oven.
H
Therefore,
it's
that
white,
documentation
and
stuff
like
that
is
now
a
variety
that
it
first
needed
to
grow.
Correct
me
best
best
Australian
were
between
all
elements
and
easy
to
use.
On
the
other
side,
we
are
trying
to
find
the
right
buttons
right
now
and
once
that's
done,
we
will
not
pass
and
before
kids
I
think,
but
for
now
it's
just
it's
too
messy,
but
problem
I
have
I,
don't
know
what
Union
yeah.
A
No
I
completely
understand
the
position
you
guys
are
in
I'm.
Actually,
I've
talked
to
one
about
this
little
bit
and
and
I.
You
know
I,
you
know
it's
not
in
the
context
of
rust,
and
one
of
the
things
that
we
were
talking
about
is
like
that.
There's
a
certain
level
of
efficiency
that
you
have
when
everyone's
in
the
same
office
that
you
can't
have
when
people
are
distributed
and
but
the
benefit
of
distributed
is
anyone
in
the
world
can
contribute,
and
so
okay.
A
So
his
perspective
is
let's
tolerate
the
inefficiency
and
so
that
we
can
have
more
contributors.
Now
that
said,
I
don't
want
him.
I,
don't
want
to
like
waste
your
guys
time
doing
a
bunch
of
busy
work
that
or
work
that
is
too
hard
to
to
ill
defined,
to
even
specify
right
now,
so
I'm
not
sure
what
the
right
answer
is.
H
Like
right
now,
the
object
like
I
started
feeling
the
the
object
actually
just
puts
it
would
be
approached
her
me.
I
only
know
I
discuss
with
someone
I,
don't
remember
who
maybe
it
was.
Why
are
you
sleeping
I?
Not
because,
but
like
that's,
what
I
have
in
my
head
right
now,
as
I
said,
documentation
is
unfortunately,
something
we
do
so
I
figured
out
the
whole
architecture
properly.
A
Actually,
don't
think
that's
an
unreasonable
objective,
I
mean
we'd,
call
it
something
like
improved
quality,
but
but
I,
don't
think
yeah
I,
don't
think
that's
necessarily
a
bad
objective.
It
does
get
a
little
hard
to
measure
because
bugs
just
come
up
out
of
nowhere,
I
mean
if
you
knew
in
advance
how
many
all
the
but
all
the
bugs
for
you
just
would
wouldn't
have
made
the
mistake
in
the
first
place.
A
D
A
A
Yeah
I,
don't
I,
don't
see
anybody
raising
their
hand,
so
I'm
gonna
assume
this
people
are
comfortable
with
ending
the
meeting.
Now.
Okay
I
see
a
thumbs
at
least
one
thumbs
up.
Okay,
all
right!
Well!
Thank
you,
everybody
for
your
time.
Yeah
we'll
will
converse
more
about
this
in
github
and
we
also
have
in
the
p2p
call
on
on
Monday.
So
if
there's
things
that
we
really
need
to
talk
about
synchronously,
we
can
do
do
it
them
so
so
I
have
a
good
have
a
good
day.
Everyone
or
at
night.