►
From YouTube: Improving IPFS specifications - Lidel
Description
Significant progress is being made around spec coverage and improvement proposal (IPIP) process. Where we go from here?
A
My
name
is
marchilada
my
handling
Slidell
I'm,
part
of
ip5
stewards
group
working
for
protocol
labs
for
a
while,
so
the
status
update
for
this
quarter
about
the
state
of
ipfs
specifications.
Hopefully
it
will
be
short.
I
will
just
briefly
mention
why.
Why
are
we
investing
in
specs?
What
are
two
major
problems
around
specifications
in
a
project
like
ipfs?
What
is
the
recent
progress
around
improving
our
spec
posture
and
what's
the
new
future
holds
so
this
year
is
pretty
important
for
this
kind
of
a
work.
A
We
see
the
growing
need
for
specifications
and
it's
not
artificial
need.
We
see
multiple
implementations
of
ipfs
popping
up
and
we
also
are
moving
in
a
direction
to
create
a
space
and
create
a
mental
model.
That's
implementations
like
go,
ipfs
are
not
ipfs,
ipfs
is
a
protocol.
Just
like
you
have
multiple
clients
and
servers
of
HTTP.
Those
are
implementations.
A
The
protocol
and
implementation
is
separate
and
for
the
protocol
you
need
a
specification.
So
one
thing
this
year
we
rename
go
ipfs
to
Kubo.
We
will
be
most
likely
doing
similar
thing
in
Json.
We
have
multiple
implementations
now
in
different
languages,
for
different
use
cases,
and
every
implementation
is
a
special
snowflake.
It's
built
from
different
parts
of
our
stack,
not
every
implementation,
like
the
two
implementations
do
not
Implement
all
the
parts
they
focus
on
things
that
are
relevant
to
their
use
cases.
A
Another
reason
for
specifications
is
that
we
started
slowly
but
surely
reaching
out
to
various
standards,
bodies
and
policy
organizations
to
register
or
start
a
process
of
standardizations
of
those
blocks
of
our
stack.
The
beginnings
are
small.
We
registered
a
tag
in
the
Civil
registry.
We
have
some
content
types.
We
are
talking
with
Ayana.
We
are
talking
with
iitf
about.
Maybe
we
should
have
RFC
for
multibase
or
multi-hash.
At
least
the
discussion
just
started
recently.
A
One
thing
is
it's
not
a
static
thing?
You
want
to
be
able
to
evolve
specifications,
and
probably
the
bigger
problem
is,
if
you
have
a
gaps
in
the
specs,
that's
the
bigger
problem,
because
it's
like
a
black
hole
of
the
resources
in
time.
You
need
to
sync
to
solve
that
problem
and
that's
like
why
we
are
focusing
on
the
second
one,
filling
the
gaps,
and
this
year
we
finally
landed
specifications
of
HTTP
gateways.
A
Most
of
implementations
now
will
be
able
to
follow
the
spec.
Don't
look.
What
Kubo
does
Do
Your
Own
Thing
in
the
most
efficient
way
in
your
own
use,
for
your
use
cases
for
your
users.
We
have
specs
for
path
gateways.
We
have
specs
for
subdominal
behaviors
DNS
link
gateways
also
recently
added
trustless
retrieval
as
blocks
on
cars.
Everything
is
in
the
ipfs
specs
repo
in
the
HTTP
Gateway
subdirectory.
A
Similarly,
when
we
are
moving
beyond
immutable
content,
ipns
is
the
only
naming
system
which
does
not
include
blockchain
and
does
not
include
a
Reliance
on
centralized
things
like
DNS,
and
there
are
many
users
of
ipns
and
people
been
asking
and
trying
to
implement
it.
How
do
I
create
ipns
record?
How
do
I
verify
it?
How
do
I
make
sure
Legacy
clients
are
still
able
to
upgrade
firmware
and
other
Mission
critical
things
over
ipns
without
being
broken
or
cut
off
from
the
update
channel?
So
we
now
also
merge
ipns
specifications.
A
A
How
do
we
represent
files
and
directories
and
not
just
small
things,
but
how
do
you
Implement
sharding
for
things
like
Wikipedia
mirrors
implementers
should
be
able
to
follow
specs
and
not
have
to
dig
into
Legacy
go
and
JS
code
to
be
able
to
load
that
and
the
serialize
UXF
as
Docs,
so
assuming
that
that
Gap,
that
problem
is
being
solved
and
that's
like
long
long
term
process
of
filling
the
gaps
at
the
same
track.
At
the
same
time,
we
have
this
parallel
track
of
work
of
improving
existing
specifications.
A
We
have
Gateway
specs,
we
have
ipns
and
other
things
IPL
the
p2pr
in
a
way
better
shape
than
ipf
specs.
Repo
was
a
few
months
ago.
Once
we
have
specs.
How
do
we
improve
that?
Well,
there's
probably
need
some
process
and
when
people
think
about
process
for
maintaining
changing
specifications,
they
literally
shut
off
and
probably
stopped
listening
to
presentations
like
this,
so
I
I'll.
Just
briefly
reiterate
what
I
presented
in
Iceland
a
few
few
weeks
ago,
we
introduced
a
very
light
process.
A
We
are
starting,
small
and
and
we'll
be
growing,
depending
on
the
needs
and
the
way
our
community
evolves.
So
we
introduced
interplanetary
improvement
process.
That's
like
a
generic
name
for
evolving
process.
You
can
read
about
it
in
ipfs,
specs
report,
there's
always
a
canonical
version.
I
will
not
go
too
deep
in
the
process,
because
the
talk
will
not
age
well,
but
the
idea
was
to
remove
barriers
and
not
add
more
reduce
overhead
instead
of
adding
cognitive
overhead.
How
do
I
propose
something
reuse,
existing
tools
that
Community
have
been
using
for
years?
A
A
So
this
is
how
it
works
today,
and
this
part
May
age
a
little
bit
but
giving
people
an
idea
of
the
complexity
involved
in
ipfs
specs
repo.
There
is
a
ipib
subdirectory
and
that's
kind
of
like
an
audit
trail
of
historical
Improvement
proposals
that
were
accepted
and
we
have
a
temp
and
on
the
screenshots
itself,
one
we
have
template
and
the
very
first
Improvement
proposal
proposes
process
for
improvement
proposals
and
the
gist
of
that
document
is
that
the
ipip
document
documents,
no
motivation,
explains
the
scope
of
the
Delta
proposed
against
ipfs
specifications.
A
A
It's
like
a
rubric
and
the
the
idea
behind
this
is
to
avoid
back
and
forth
when
someone
proposes
Improvement
or
a
new
specification
for
something
totally
new,
avoid
back
and
forth
on
the
most
the
common
things
common
theme
like.
Why
are
you
proposing
this?
What's
the
value
added
to
the
end
user?
What's
the
user
benefit?
How
is
it
compatible
with
wider
ecosystem?
A
What
are
security
consideration?
What
is
your
threat
model
around
that?
An
important
part
we
in
this
process,
we
are
including
test
fixtures.
So
if
you
propose
something
especially
if
it's
we
are
talking
about
protocols,
you
should
guide
people
into
how
to
test
the
thing
and
for
things
related
to
data,
provide
cids
with
example,
dogs.
So
people
can
use
edge
cases
that
the
person
that
created
a
proposal,
things
implementations
should
follow.
A
Current
process
is
very
simple:
pull
request
against
the
spec
repo
copy,
the
template
fill
the
gaps,
don't
stress
too
much.
We
will
working
ipfs
towards
specs.
Spec
stewards
will
work
with
you
to
get
you
to
the
point
when
it
can
be
brought
up
to
avoid
Their
audience.
We
already
did
one
iteration
of
the
process.
That's
why
I
said
it
may
age
not
well,
but
we
have
are
having
like
bi-weekly
I,
believe
ipfs
implementersing
and
discussing
IP
IPS
on
that
call.
It's
a
part
of
agenda.
A
So
essentially
we
when
we
meet
once
or
twice
a
month.
We
flag
potential
protocol,
Improvement
proposals
for
other
implementers
from
the
leads
from
different
ipfs
implementations
to
review
like
asynchronously,
read
it
and
the
next
time
we
meet
we
may
discuss
this.
Is
it
a
good
idea?
Do?
Is
it
something
we
want
to
standardize
and
then
we
are
working
together
towards
merging
the
spec?
It's
a
very
long.
It's
not
something!
We
want
to
rush
it's
ongoing
process,
but
it's
a
basic
structure.
A
So
people
know
someone
will
look
at
their
proposal
and
they
will
not
be
stuck
in
a
vacuum.
So
up
to
date,
version
is
always
in
ipfs
Spec
repo.
It
in
current
version
includes
the
life
cycle
of
your
proposal.
So
if
you
want
to
know
like-
oh
what's
that
supposed
expectation
to
like
hear
from
stewards
or
have
someone
to
review
it,
details
are
on
the
document
and
I
will
briefly
show
a
few
examples,
because,
since
we
announced
ipip
process
in
Iceland,
we
already
landed
some
things.
A
So
fission
submitted
a
proposal
to
support
redirects
files
on
web
gateways,
so
subdomain
gateways
and
DNS
link
gateways,
which
deserialize
data
and
act
as
a
regular
HTTP
server.
You
can
use
them
essentially
as
a
replacement
for
nginx
or
other
HTTP
server
or
behind,
and
they
enable
a
standard
way
of
doing
things
like
catching
a
catching
non-existing
Pages
for
single
page
applications.
Redirecting
existing
links
presenting
a
nice
404s
that
landed
and
it's
a
good
example
of
our
ipip.
It
includes
the
test
fixtures
of
those
files
that
you
can
include
in
your
own
test
harness.
A
So
you
are
sure
you
are
testing
what
the
person
that
created
specification
intended
as
the
minimum
bar
for
implementation
and
I
feel
it's
very
important
that
by
including
the
test
fixtures
in
the
specification
itself
around
something
like
ipfs.
When
we
talk
about
content
address
data,
we
we
have
more
confidence
in
our
implementations.
A
A
This
one
also
has
like
a
test
fixtures
and
a
security
section
with
some
considerations
for
implementers.
So
it's
a
good
example
of
how
we
hope
the
process
to
follow.
To
always
like
include
that
rubric
and
there's
like
a
bunch
of
ipips
in
progress,
the
one
I
highlighted
is
adding
Json
and
sible
support
to
gateways,
so
we
can
go
beyond
files
and
directories.
A
So
the
question
is
like:
where
do
we
go
from
here?
One
we'll
be
refining
ipip
process
depending
on
feedback
from
people
who
submit
ipips
will
be
dropping
unnecessary
overhead
will
be
refining
templates
and
will
be
adding
process
making
sure
the
ipibs
are
triaged
and
processed
to
the
pipeline
smoothly.
A
It
kind
of
like
a
bigger
picture
is
to
unify
spec
life
cycles
and
standards
across
entire
ipfs
stock,
and
by
that
me,
I
mean
ipfs,
but
also
things
that
we
use
internally
ipld
P2P
multi-formats.
Each
sub-project
has
own
spec,
repo
or
website
with
different
standards.
Different
degree
of
maturity
we
want
to
unify
the
process
set.
A
The
similar
expectations
for
entire
community
and
part
of
that
story
is
to
have
a
single
publication
location,
not
saying
that
we
will
be
like
merging
all
the
repos,
but
we'll
have
a
single
place:
One
Stop
Shop
when
you
go
and
you
can
see
specs
for
everything,
that's
relevant.
If
you
want
to
implement
ipfs
gateways.
A
Parts
of
the
P2P
Academia
DHD
should
be
accessible
from
a
single
View
and
you
should
be
able
to
zoom
in
to
a
specific
spec
of
a
specific
subsystem
from
that
One-Stop
shop.
An
improved
presentation,
Beyond
just
markdown
on
GitHub
and
make
it
easier
for
people
to
contribute
like
people
could
create
specs
people
who
create
a
Improvement
proposals
should
be
able
to
like
edit
it
locally,
have
a
previews
and
pull
requests.
A
If
the
test
fixture
cids
are
included
in
the
spec
itself,
we
should
make
sure
it's
available
on
the
public
DHD
that
other
people
other
implementers
are
able
to
fetch
and
I'm
wrapping
up.
But
it's
it
takes
a
village,
so,
as
ipfs
steward
I
want
to
invite
people
to
participate
in
this
process
depending
on
the
area
of
expertise,
review,
comment
or
pull
requests,
namely
ones
that
are
ipipps.
The
more
questions
there
are
the
better
end
result
is:
do
you
want
to
improve
something?
A
A
Another
thing:
if
you
feel
there
is
a
problem,
but
you
don't
have
a
solution
yet
and
you
don't
want
to
add
a
noise
to
the
ipip
process.
We
have
a
discussion
forums
and
there's
a
protocol
category
there,
where
you
can
incubate
ideas
and
flesh
out
the
Technical
Solutions
to
them,
and
then
that
solution
could
be
submitted
as
ipip
and
that's
it.
Thank
you.