►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi,
I'm
lidl
I'm
working
at
protocol
labs,
I'm
part
of
iphone,
stuart
and
today
I'll
be
talking
about
ipip,
which
is
interplanetary
improvement
process.
For
now
it's
for
ipfs
specifications
repo,
but
it's
pretty
good
name.
I
guess
so.
I
will
go
over
four
points
why
we
need
a
process.
What
were
the
guiding
principles
behind
the
process
in
the
current
form,
I'm
proposing
how
it
works?
A
A
A
Nothing
will
happen
or
will
be
stuck
with
the
old
old
decision
and
if
there's
this
stagnation,
that
means
people
who
want
to
implement
new
things
and
are
very
determined,
the
smaller
subset
of
people,
because
many
people
will
just
give
up,
they
will
look
at
the
oldest
implementation
of
ipfs
as
oh,
that's,
the
source
of
truth,
there's
no
spec,
but
we
have
those
two
implementations
and
they
have
interrupt
between
them.
For
some
reason,
maybe
that's
the
source
of
truth
and
overall
people
see
oh
people
who
want
to
implement
new
thing.
A
A
So
we
want
to
remove
barriers,
not
add
new
ones.
We
want
to
people
are
busy
already
with
want
to
like
there
will
be
overhead,
but
it
has
to
be
minimum
and
minimal.
So
we
need
to
follow
existing
conventions,
reuse,
existing
tools.
We
already
have
a
reputation
system
based
on
github
and
git
home,
it's
history
and
so
on.
We
already
doing
triages
using
tools
based
on
github,
git
and
so
on.
A
We
want
to
avoid
the
byzantine
processes
where
you
don't
even
know
who
to
talk
to,
or
what's
the
next
step
or
you
need
to
like,
follow
the
organizational
diagrams.
All
that
should
not
happen.
It
should
be
like
all
in
public,
transparent
and
also
like
that
being
transparent
in
public
forces.
Ipfs,
stewards,
spec
stewards
to
review
things,
because
the
queue
of
things
that
people
propose
not
being
reviewed
looks
bad.
A
So
I
think
it's
beneficial
for
everyone
to
behave
well,
and
I
need
to
address
this
because
someone
will
ask
this:
why
not
rfc?
We
had
a
discussion
about
that.
Initially,
it
was
suggested
to
be
rfc,
but
then
rfc
means
different
things
depending
on
the
project
and
the
biggest
rfc
is
from
itf,
and
it
means
a
totally
different
thing
than
the
meaning
is
different
across
projects.
In
some
projects
it
means
request
for
comments
in
other
projects.
It's
request
for
change.
Sometimes
it
describes
the
delta
of
the
spec.
A
Sometimes
it's
the
spec,
sometimes
it's
the
spec
and
how
you
use
the
spec
so
just
to
avoid
confusion
depending
so
to
avoid
confusion
for
for
by
the
fact
that
people
come
from
different
backgrounds
and
have
different
notion.
What
rfc
is
we
just
went
with
our
own
name,
so
I
briefly
show
you
some
markdown
screenshots
how
the
process
works.
A
A
Literally,
the
entire
talk
could
be
summarized
into
this
one
line.
The
purpose
of
improvement
proposal
document
is
to
document
motive,
motivation
behind
the
change
and
not
being
the
spec
itself.
So
it's
a
description
of
the
delta.
If
you
have
nothing-
and
you
add
a
new
thing,
you
explain
why,
if
you
have
something-
and
you
change
something,
you
explain
why
and
how
would
you
propose
improvement
proposal
using
this
system?
A
A
Oh,
if
I
want
to
evaluate
this
improvement
proposal,
I
go
to
that
document
first,
and
that
makes
it
easier
not
only
for
spec
stewards
to
reveal
proposals,
improvements,
but
also
for
community
to
have,
as
the
community
have
a
common
audit
trail
of
historical
decisions.
Sometimes
we
end
up
with
things
which
may
not
be
obvious.
A
Why
we
make
those
strange
decisions
and,
right
now
the
knowledge
is
scattered
across
repos
or
even
worse,
across
brains,
we
want
to
start
tracking
decisions,
so
we
stop
spinning
wheels
explaining
over
and
over
why
we
made
some
decisions
and
we
can
just
refer.
People
to
the
template
itself
is
focused
on
motivation.
A
A
There
are
different
aspects,
different
dimensions
you
need
to
cover-
or
at
least
mention
when
you
are
proposing
something
user
benefit
compatibility
with
existing
ecosystem
or
non-ipfs
ecosystem
security
and
what
are
other
ways
of
doing
the
things
you
are
proposing
and
why
you
did
not
pick
those
things.
So
it's
just
like
a
list
of
bullet
points
that
helps
people
to
flesh
out
things
and
also
speeds
up
reveal
process,
because
we
avoid
back
and
forth.
Oh
could
you
what
about
security?
No
like
when
you
create
a
proposal?
A
You
already
have
those
blank
slates
that
you
need
to
fill
out
and
right
now
the
idea
is
best
effort,
very
informal
process
where
spec
stewards
will
just
like
we
implemented,
have
a
weekly
or
bi-weekly
triage.
We
will
have
a
triage
of
incoming
improvement
proposals
and
we'll
get
it
from
there,
we'll,
probably
improve
process.
If
we
see
we
need
some
policies
around
making
some
decisions
we'll
make
new
improvement
proposals
clarifying
that
or
will
adjust
as
we
go,
but
this
is
like
a
starting
point.
A
At
least
we
have
some
and
some
common
ground
for
proposing
improvements,
and
I
will
end
this
with
a
call
for
ipips
and
just
as
for
the
four
thoughts
I
will
show
some
already
opened
pull
requests.
They
may
not
use
the
latest
version
of
template,
but
ignore
those
are
like
editorial
changes.
Of
course,
we'll
before
we
merge
them,
they
will
be
aligned
with
the
latest
templates.
A
So
we
recently
landed
a
bunch
of
http
gateway
specs,
so
most
of
improvement
proposals
are
against
that,
because
this
is
what
happens
when
you
have
specs
that
describe
the
thing.
People
know
how
the
thing
work.
They
may
propose
delta
against
it.
If
you
don't
have
the
description
of
the
current
states,
people
are
not
able
to
propose
delta,
so
maybe
gateways
subdomain
gateways
and
dns
gateways
which
are
used
in
the
browser
for
website
hosting.
A
Those
are
just
initial
proposals
that
happened
right
after
we
created
gateway
spec.
Even
before
we
had
the
improvement
proposal
process,
some
were
created
and
then
readjusted
to
reuse
the
template,
but
it
kind
of
shows
that
when
you
give
people
venue-
and
you
provide
a
very
easy
convention
like
people-
don't
need
to
read
the
improvement
proposal
like
the
first
one,
they
could
look
at
existing
like
last
two
proposals
that
got
merged
and
do
the
same
thing
or
just
copy
the
template
and
wing
it,
and
I
think
that's
fine.
A
A
A
A
Consume
like
senior
people
consuming
specs
people
who
are
invested
in
spec
quality
to
contribute
and
share
the
responsibility
of
reviewing
and
another
question
potential
question
is:
how
would
we
do
the
testing,
so
I
kind
of
like
try
to
answer
that,
but
different
specs
will
have
different
text
fixtures
different
ways
you
think
about
testing.
So
we
we
will
not
have
a
single
test
harness
for
ipfs.
A
A
Yeah,
I
believe
there
will
be
talk
about
exactly
how
that
works
and
who
who's
calling
the
shots.
The
short
answer
is
right.
Now
it's
owned
by
protocol
labs
and
I
think
the
implied
question
is:
should
we
maybe
move
ipfs
specs
to
different
org,
or
should
we
discuss
the
long-term
ownership
of
ipfs
org
as
a
whole
should
maybe
be
transferred
to
foundation
it's
like
kind
of
out
of
the
scope,
but
it
would
be
useful
to
understand
how
things
work
right
now.
So
I
believe.
C
Just
a
comment
looking
at
some
of
the
things
in
there
definitely
see
inspiration
from
a
lot
of
other
systems.
Yes,
let's
talk
about
how
to
generate
web
pages
and
publish
them
to
ipfs
from
those
markdown
files.
I
think
one
of
the
things
that
always
comes
up
with
this
that
we
should
do
early
on
is
a
cla
process
to
make
sure
that
all
of
the
ip
in
there
is
is
cleared
yeah.
A
C
There's
a
bunch
of
bots
and
other
stuff
like
that,
so
we
have
it
for
the
you
can
spec
that
that
brook
set
up.
So
I
think
that
there's
some
and
we
in
turn
used
that
as
a
template
from
a
repo
that
was
a
good
bottoms-up
community
process.
So
I
already
saw
that
you
had
cc0
on
there,
which
is
great
and
a
few
little
more
things,
and
then,
ideally,
I
think
one
of
the
goals
should
be
everything
from.
A
As
I
said,
I
kind
of
like
started
with
prompts
this
entire
thing
is
a
prompt
and
I've
put
cc0
just
to
spark
a
discussion.
I'm
not
saying
that's
the
way,
but
at
least
it's
there,
so
someone
can
propose
delta
and,
I
think,
creating
a
improvement
proposal
that
clarifies
our
excuse.
Me
clarifies
our
like
stance
around,
but
things
like
pata,
because
you've
got
copyrights,
you
got
licenses
and
you
also
got
patents
and
those
are
things
which
I'm
not
experts.
B
A
A
However,
with
what
you
are
testing,
so
I
think
I
feel
the
project
shows
a
interesting
prior
art
in
that.
Yes,
this
project
focused
on
data
structures
and
so
on.
But
if
you
look
at
their
specs
every
spec
for
things
like
duck,
pb
dac
seabord.json
and
cars
or
whatever
they
have
test
vectors,
they
have
files
which
test
all
the
edge
cases
and
people
who
create
the
specs
know
where,
like
the
bodies,
are
buried
right.
A
So
if
anything
goes
wrong
across
different
languages
implementations,
it
will
be
oh
in
this
car
because
we
use
all
three
formats
and
so
on.
So
I
think
first
thing
is
to
create
a
culture
and
also
a
prior
body
of
specs
with
test
fixtures
which
describe
how
to
use
test
vectors,
and
then
we
may
may
decide
that,
oh
for
the
gateways,
it
makes
sense
to
have
some
ci,
which
runs
against
gateway.
So
you
can
maybe
run
a
cli
tool
and
test
your
own
gateway.
A
A
So
I
think
we
should
focus
more
about
having
test
data
test
vectors
first
and
then
we
can
figure
out,
because
maybe
that
do
we
need
a
generic
thing
like
for
something
like
gateway
sure,
but
for
bitswap,
probably
implementations
may
want
to
create
their
own
tests
and
just
use
maybe
frames
from
the
spec
as
those
vectors.
So
we'll
see.
B
A
If
you
have
a
pretty
fleshed
out
idea,
I'd
say
copy
the
template
and
just
add
something.
You
there's
also
a
template
for
the
spec
itself.
So
if
you
want
to
add
a
totally
new
thing,
let's
say
I
have
in
the
process:
I've
used
webdav
gateway
as
an
example.
If
you
want
to
add
the
new
thing,
you
would
add
improvement
proposal
document,
arguing
why
it's
a
good
idea.
What's
the
motivation
and
so
on,
and
then
you
would
add
the
second
file
with
the
spec
itself.
D
A
Yeah
totally
so
just
to
be
clear,
I
I
misunderstood
also
so
in
in
the
in
the
document
described
in
the
process.
Ipip
the
first
one,
there's
a
description
like
things
like
editorial
changes,
which
don't
change
the
the
meaning
of
the
spec
or
adding
more
detail
which
don't
change
interop.
That
could
be
a
pr
without
improvement
proposal.
However,
if
you
add
something
which
may
mean
we
suddenly
add
more
burden
to
implementers,
then
it's
probably
like
ipip,
but
we
will
figure
out
the
policy.
C
I
think
in
general
and
I
think
for
this
track
generally,
I
would
love
to
find
the
canonical
descript
discussion
space,
so
I
would
probably
file
a
pr
saying:
don't
do
the
written
version
of
why
you
should
care
about
this
thing
in
this
spec
rebo
at
all,
because
that's
the
sort
of
opinion
discussion
thing
and
you
don't
go
straight
to
a
spec.
You
talk
about
it
before
you
do
a
spec,
so
in
other
communities
that
have
been
a
part
of
discourse,
forums
have
been
used
very
successfully
for
this.
There
remain
other
questions
like.
C
A
B
Questions,
do
you
have
any
thoughts
on
like
the
only
way,
I've
ever
really
seen
interrupt,
get
done
in
an
expedient
ways
like
with
economic
incentives
to
do
it
and
or
economic
disincentives
to
not
do
it.
Otherwise,
it
just
seems
like
you
treat
the
standard
as
a
commons
that
can
be
extracted
from,
as
opposed
to
like
getting
people
to
actually
like
interrupt
in
the
standard
so
like
giving
from
your
perspective
working
on
this
for
so
long
like
do
you
have
any
ideas
like?
A
A
If
it's
in
their
best
interest,
I
think
just
figuring
out
a
way
to
kind
of
like
game
it
so,
for
example,
make.
I
think
the
way
we
structure
specs
also
could
translate
to
that
and
I'll
give
an
example.
Instead
of
having
a
single
spec,
which
says
you
need
to
implement
blocks
cars,
you
need
to
implement
unix,
fs,
daxibor.json,
oh,
and
also
that
jose,
because
everyone
wants
the
encryption
and
so
on.
You
suddenly
made
it
impossible
for
someone
who
does
not
care
to
do
the
right
thing.
A
However,
if
you
decompose
specs
into
distinct,
primitives
and
say,
like
I
I'll
use
gateway,
because
I'm
the
most
familiar
with
that,
for
example,
you
have
distinct
layers
in
the
gateway
spec
around
response
types,
so
people
who
don't
care
about
websites
or
don't
want
to
use
their
gateway
for
the
delegated
hosting
of
third
party
files.
They
may
not
implement
unicefs
at
all.
They
may
not
implement
that
part.
A
They
may
only
implement
block
and
car
responses,
and
if
we
make
it
clear
in
the
specs
that
you
don't
need
to
do
the
entire
thing
people
will,
if
we
define
those
like
stop
points
hey,
you
can
do
this
and
say
that's
enough
for
me.
You
can
do
this
and
you
get
this
additional
interoperability
and
you
can
do
this
additional
thing.
I
think
we
cannot
expect
everyone
will
do
everything.