►
From YouTube: IPFS All Hands 🙌🏽📞 Aug 06, 2018
Description
The video file goes missing, we discuss meeting format changes, and talk about dwb protocol handling in browsers, on the IPFS all-hands call.
https://github.com/ipfs/pm/issues/669
B
All
right
welcome
to
this
week's
August
6th,
ipfs,
All,
Hands,
meeting
I.
Think
we've
got
a
reasonably
slim
agenda
and
Johnny
crunch
is
gonna,
be
note-taking
today,
so
welcome
and
I
think.
The
first
thing
we've
got
today
is
Matt
wanted
to
talk
about
the
potential
formats
which
that
we've
been
sort
of
noodling
about,
but
nothing
can't
create.
Yet
for
this
call
so
kind
of
changing
it
up
how
it
works.
B
A
So
this
is
also
to
address
the
slim
agenda
so
now
that
we're
done
with
all
the
developer
meeting
planning
and
the
web
summit
planning,
and
all
of
that
we
have
the
heads
face
to
follow
through
on
this.
So
this
week,
I'm
going
to
set
up
will
so
the
proposal
which
did
I
link
to
it.
Oh
no
I
grabbed
the
link
and
then
I
didn't
add
it
to
the
there
I've
added
the
link
to
the
notes.
So
the
proposal
is
there:
it's
been
out
for
a
long
time.
Nobody
has
disagreed
with
it.
A
It's
the
idea
of
being
set
a
schedule
even
like
months
out
that
every
week
having
having
this
disc
all
be
formatted
around
presenters.
So
you
would
have
an
invited
presenter
for
each
Paul,
who
would
give
maybe
a
20
minute
presentation
and
have
some
Q&A
and
then
maybe
also
insert
a
couple
demos
like
we've
been
doing
and
then
basically
community
announcements
somewhere
in
there,
either
at
the
beginning
or
at
the
end,
and
so
the
hold
up
there
is
that
nobody
had
time
to
actually
set
the
schedule
of
presenters.
A
And
so
now
I
have
time
to
set
the
schedule
of
presenters
and
I'm
wondering
who
would
like
to
help
me
set
that
schedule.
I.
Think
Michael
should
at
least
be
involved,
and
then
Dominic
has
been
hosting
first
for
a
very
long
time,
so
Dominic
if
you'd
like
to
join.
But
it
is
anyone
else
interested
in
helping
us
set
that
list
for
the
first
round
of
presenters.
A
Okay,
well,
then,
I
will
follow
up
with
Dominick
and
Michael.
I
already
have
a
pretty
lengthy
list
in
mind
and
it's
more
of
a
question
of
figuring
out
who's
available
when
and
so
we
can
set
up
at
it,
set
up
a
schedule
and
that
will
actually
hopefully
change
the
flow
of
this
call,
because
we
can
also
at
that
one
we're
setting
schedule.
We
can
also
set
the
moderator
and
it
really
reduces
the
burden
for
the
host,
which
I
think
we
should
be
rotating
the
host
pretty
certain.
A
C
B
A
Okay,
well,
then,
then,
Robin
might
loop.
You
into
this
will
be
mostly
just
by
email
of
like
I'll
put
together
the
draft
of
the
list,
and
then
oh,
the
people
who
I
just
named
are
mainly
your.
The
people
are
gonna,
be
see
seed
on
the
emails
when
I
reach
out
to
people
and
say
hey
who's
available
with.
C
C
Cool,
so
a
little
bit
of
background
Libby
Webb
is
a
community
effort,
it's
littered
by
Mozilla
and
good
friend,
because
Allah
it's
a
community
effort
to
add
additional
api's
to
web
extension
specification.
Web
extension
is
like
a
common
set
of
common
api's
that
browser
browsers,
such
like
firefox
and
chrome,
implement
to
make
it
possible
for
people
to
write
extensions
and
our
extension.
Ipfs
companion
would
really
benefit
from
those
new
api.
As
you
can
see
here,
those
are
basically
missing
missing
pieces
of
the
puzzle
to
have
the
same
connectivity
magic.
C
So
that's
the
dream
to
have
those
api's
and
the
first
one.
A
protocol
handler
is
ready
to
try
it
out
and
that's
basically,
what
we've
done
I
got
here.
I've
got
a
experimental
built
of
our
browser
extension
and
that
runs
in
Firefox
nightly.
You
can
see
it
here.
It's
it's
like
the
latest
Firefox
whatnot
latest
from
last
week,
Firefox
nightly
and
what's
interesting
about
that
is.
C
There
is
documented
on
our
companion,
repo,
that's
basically
this
there's
like
one
or
two
commands
that
you
can
execute
and
you
can
build
an
entire
environment
locally.
If
you
wants
to
play
with
it,
see
how
such
protocol
handler
works
in
the
regular
browser,
that's
it
for
the
pronged,
preface
let's
go
to
the
actual
demo,
so
I
have
a
list
of
list
of
experimental
resources.
So
basically,
if
you
have
like.
C
C
So,
like
image,
is
an
easy
one.
What's
about
like
what
about
directory
tree,
because
my
PFS
would
go
to
directories
so
basically
got
the
same
experience
like
you
would
open
ipfs,
io,
/
ipfs,
you
can
traverse,
you
can
traverse
entire
entire
tree.
Maybe
this
one
yeah,
so
the
directory
traversal
works.
C
C
What's
even
more
interesting
is
that's
like
JavaScript
works
in
those
websites,
as
expected,
if
I
can
like
grab
an
a
hash
to
demonstrate
that,
because
this
is
a
simple
web
page
running
JavaScript
and
you
can
see
like
works
like
a
regular
web
page.
What's
actually
interesting.
Is
that
all
the
pages
that
had
DNS
linked
already
law
just
fine?
So
this
is
a
mirror
of
Turkish
Wikipedia
we
made
when
we
keepin
ya,
got
blocked
in
Turkey
and
you
can
see
it's.
You
can
basically
browse
it
like
well,
maybe
not,
and
not
this
one.
C
A
C
So,
basically,
that's
why
I
created
this
one
simple
comment:
to
build
the
entire
thing
and
let
people
to
run
it
locally.
The
idea
is
that,
right
now,
this
API
is
a
prototype
that
we
can
play
with
and
report
all
the
issues.
I
have
a
list
of
issues
that
I
will
be
adding
to
divide
people
to
tell
you
myself,
but
if
any
has
time
and
once
or
have
let
say,
I
pianist
website
that
they
developed
and
want
to
check.
C
So
this
is
the
stage
when
we
try
to
polish
this
API
to
the
point
that
can
be
proposed
for
uplifting
to
the
like
the
better
channel
and
then
to
the
stable
channel.
But
right
now
we
have
problems
with,
for
example,
when
you
start
up
playing
video
and
want
to
jump
forward
in
HTTP,
you
had
a
Content
rage,
header,
but
that's
a
part
of
HTTP,
and
we
don't
have
that.
So
how
do
we
address
it
in
ipfs
protocols?
C
Those
are
like
opening
problems
that
if
anyone
has
ideas
you
can
contribute
those
ideas
or
questions
to
mozilla
lib.
Do
a
propósito
dialect
directly
or
just
send
them
to
me.
We
are
or
just
visit
our
RC
channel
and
we
can
brainstorm
it
together.
So
that's
the
current
state.
We
want
to
experiment
with
it
as
much
as
possible
and
make
sure
and
break
things
right
if
we
are
able
to
break
things
now,
that's
perfect
because
it's
what
we
want.
C
We
want
to
find
problems
as
soon
as
possible
before
we
promote
this
API
further
and
when
it's
like
promoted
at
some
point
in
future,
when
it's
promoted
to
Firefox
stable
channel,
then
we
can
propose
this
API
to
like
web
extensions
back
working
group
in
w3c,
so
that,
like
other
vendors
can
adopt
and
they
have
already
working
API
spec
and
already
implemented
extensions
that
consume
those
specs.
So
what
the
only
thing
they
do
is
to
implement
API
and
then
we
they
will
get
a
value
added
by
those
extension
for
free,
basically
right,
so
that's
my
overview.