►
From YouTube: IPFS Goes Mobile - Fabrice Desré
Description
Capyloon is an experimental web based mobile OS. It aims at giving users more control over their digital life, with decentralized technologies as a cornerstone of the solution. We'll talk about the early steps, current status and what to expect next.
A
So
the
base
is
it's
it's
a
dissonant
of
the
work
that
was
done
on
Firefox,
OS
and
kaios,
and
it's
a
very
user-centric
mobile,
webos
and
a
way
to
experiment
with
new
techniques
coming
from
the
decentralized
web
community,
so
mostly
ipfs
decentralized
identity.
You
can
so
a
very,
very
Central
Point
for
me
was
to
bring
back
user
agency
in
in
a
mobile
web
operating
system
and
so
we're
starting
to
work
on
that.
Arias
is
here.
A
Quite
it's
quite
ironing
that
the
the
the
devices
that
are
easier
to
work
with
as
a
one
from
Google.
But
that's
what
it
is.
We
also
have
bids
for
Linux
phones
like
the
pine
phone
and
Libra
M5,
so
these
ones
are
a
bit
more
like
nerdy
and
more
for
Archers,
but
they
are
very
important,
I.
Think
to
support
this
project.
I,
try
to
bring
more
openness
in
on
the
hardware
side
and
getting
better
Upstream
support
for
all
these
open
devices.
A
We
also
have
a
desktop
simulator,
so
it's
very
useful
when
you
work
on
the
front-end
side,
like
all
the
apps
that
run
on
this
os
are
web-based
so
it's
just
it's
just
web
apps
with
sometimes
additional
apis
compared
to
a
regular
browser,
but
you
can
just
debug
them
with
regular
Dev
tools.
Yeah,
it's
it's
gecko
based,
so
you
use
Firefox
devtools
and
it
just
works.
It's
pretty
neat
one
one.
So
one
thing
that
we
don't
try
to
do
is
be
very
similar
to
existing
osis.
That
would
makes
no
sense.
A
So
one
big
problem
with
mobile
devices
is
that
everything
is
tied
to
the
app
stores
and
how
this
centralized
a
huge
amount
of
control.
Just
because
of
this
app
stores
and
that's
supposed
to
be
yeah
general
computing
devices
like
an
iPhone
or
recent
Android
device,
it's
pretty
powerful,
but
but
actually
you
cannot
do
much
with
that
and
in
the
80s
in
France
we
had
something
called
the
minitel,
which
was
a
very
nice
device
for
for
the
time
it
was
in
the
80s.
A
So
the
the
state-run
Telco
was
giving
away
this
devices
that
look
like
BBS
Terminals
and
you
could
access
a
bunch
of
services
from
there
and
so
that
the
carrier
was
running
everything
it
was
running.
It
was
giving
the
devices
it
was
letting
service
providers
look
up
services
and
was
providing
Discovery
through
some
directory,
and
it
was
managing
payments
because
you
we
are
basically
built
on
your
phone
bill
and
and
that's
exactly
what's
happening
with
app
stores.
Right
now.
Apples
and
Google
are
concluding
what
apps
you
can
run
on
your
device.
A
They
control
depending
on
your
country,
what
you
can
do,
like?
Oh
you're,
inside
country,
no
VPN
for
you,
too
bad.
They
control
all
the
discovery.
You
have
only
access
to
the
store
itself
to
find
new
apps
compare
that
to
the
web,
but
you
have
a
bunch
of
different
search
engines,
especially
now
we
can
see
that
new
ones
coming
up.
We've
seen
the
Braves
are
changing,
which
is
pretty
good.
They
are
all
just
like:
there's
a
bunch
of
choice
now
and
and
yeah
the
control
payment
through
in-app
payments
and
and
so
on.
A
A
Then
we
have
some
lessons
that
we
can
learn
from
the
HTTP
web.
It
it's
not
a
criticism
of
how
it
was
designed
and
and
built
in
the
early
90s,
because
we
didn't
know
better,
but
it
was
not
designed
to
prevent
Civilization
by
by
a
few
big
players
like
yes,
sure
you
can.
You
can
spin
up
your
own
HTTP
server.
It's
not
that
hard!
Well,
it's
it's
a
bit
cumbersome,
but
it's
it's
doable,
but
nothing
was
preventing
big
players
from
getting
all
the
network
effects
and
and
being
very
damaged.
A
There's
nothing
also
that
helps
with
the
type
of
stability
so
that
you
can
move
your
data
from
one
service
to
another.
You,
you
you're,
expected
to
rely
on
all
this
service,
providing
new
apis
to
do
that
like
if
you
want
to
move
from
thicker
to
another
photo
provider.
It's
it's
not
necessarily
easy,
but
but
not
everything
is
bad
on
the
web.
It's
it's
still
the
best
permissionless
platform.
We
have
it's,
it's
still
very
easy
to
publish
you.
Can
you
can
create?
A
No
one,
it's
gonna,
censor
you
and,
and
so
on,
and
it's
a
very
solid
foundation.
Security
model
is
is
what
it
is.
Not
it's
not
perfect,
not
Everyone
likes
it,
but
the
same
origin
policy
and
content
security,
Acuity
policy,
for
instance
a
pretty
solid
foundation
to
to
bring
down
top
of
so
yeah.
What?
What
can
we
take
from
from
the
decentralized
web
to
to
help
us?
A
First?
We
have.
We
have
data
portability
by
Design
because
once
you
have
content-based
racing
well,
it's
it's
all
there.
You,
you
don't
need
to
worry
about
who's
really
hosting
or
created
your
your
data.
As
long
as
you,
you
know
the
the
address
we
still
have
links
as
long
as
we
have
URLs.
We
are
good.
We
have
links,
we
can
navigate.
We
can
create
this
web
of
data.
A
A
In
a
way
that
is
much
more
powerful
than
the
current
permission
model
that
we
use
on
browsers,
so
in
Cabin
we
have
a
implemented.
You
can
support
for
some
of
our
apis,
and
here
I
have
a
few
screenshots
about
how
it
looks
when
you
try
to
like
access
the
navigation
history
of
the
user.
So
at
the
app
here
will
request
access,
and
the
next
step
is
that
the
user
responded
to
say.
Okay,
do
you
want
to
let
this
application
acts
as
a
my
navigation
history
and
for
how
long
we
run
that
access?
A
A
So
in
in
capital,
I
I'm
gonna
describe
a
bit
what
we've
done
to
do:
ipfs
integration
and
where
we
started
and
where,
where
we
are
now
what
what
we
plan
to
do
next.
So
initially,
we
just
started
with
fairly
simple
protocol
and
Link
for
ipfs
and
ipns,
and
we
did
that
using
a
remote,
HTTP
Gateway,
meaning
that
behind
the
scenes,
the
protocol
and
layer
was
just
redirecting
to
a
Gateway
and
trusting
the
Gateway
okay,
so
that
that's
pretty
much
what
Javier
showed
for
for
Chrome.
It
was
very
similar.
A
The
I
think.
The
only
difference
is
that
in
gecko,
once
you
have
the
protocol
and
layer
Implement
sheet,
you
can
use
it
anywhere,
not
just
on
top
level
navigation
but
like
in
fetch
in
in
anywhere.
You
can
put
an
URL,
it
works,
and
so
we
we
implemented
that
and
we
implemented
the
uploads
to
Falcon
using
Estuary.
So
you
could
hear
that
was
during
the
last
ipf
testing
conference.
A
I
took
a
photograph
of
the
of
the
stage
you
decide
to
publish
to
ipfs.
You
can
optionally
put
a
password
to
protect
your
file
and
it
gets
uploaded.
So
we
get
a
UI
with
progress,
upload
and
then
yeah.
You
can
share
using
QR
code,
for
instance.
So
that's
not
that's
publishing
using
Estuary,
so
they
have
their
own
API
that
you
can
use
for
that.
So
it's
a
bit
different
from
what
move
has
parented
with
aggregor
publishing,
but
we
are
good
we're
gonna
at
some
point.
We're
gonna
we're
gonna,
get
something
compatible.
A
So
that
that
was
really
what
we
started
with
and
and
now
we
have
something
much
better
that
we
published
the
latest
Builder,
but
a
few
weeks
ago
we
wanted
to
get
verifiability
of
the
data
that
we
were
fetching
and
for
that
we
integrated
the
full
ipfs
node
in
in
on
the
device.
Since
we
have
control
over
the
full
stack,
we
can
do
that
in
in
a
way
that
is
not
possible
right
now
on
iOS
Android,
where
you
are
limited
in
terms
of
how
long
you
can
run
processes.
A
So
we
we
took
IO
we've
been
collaborating
with
the
team
at
Iowa
that
shipped
their
first
version
yesterday,
and
so
we
did
two
main
contributions.
One
is
that,
instead
of
using
the
micro
service
approach,
referral
with
different
processes,
one
for
peer2p
or
one
first
store
one
for
the
Gateway.
We
are
bundling
everything
in
a
single
process
and
the
other
thing
is
that,
since
on
mobile,
we
cannot
really
afford
to
run
the
peartupia
discovery
and
the
DHT.
A
We
added
the
feature
where
we
could
raise
the
peer-to-peer
stack
with
raw
access
from
a
Gateway,
the
the
kind
of
access
that
like
then
described
earlier,
and
so
once
we
add
that
we
just
disabled
the
peer-to-peer
stack.
It
means
we
just
get
all
the
resolving.
That
is
fetching
raw
content
from
the
Gateway
and
doing
all
the
verification
and
all
the
decoding.
A
So
now
we
switch
from
having
to
trust
a
remote
gateway
to
fetching
from
our
local
node
and-
and
we
know
that
we
can
trust
it,
because
it's
doing
all
the
decoding,
all
the
data,
integrated
verification,
okay
and
technically
it's
it's
using
HTTP
over
a
Unix
domain
circuit.
So
it's
it's
a
bit
more
secure
than
than
doing
plain
http.cp,
and
it
also
helps
with
some
gecko
internals,
where
we
expect
some
HTTP
channel
for
caching
and
so
on.
A
A
The
highlighted
line
is:
is
the
ipfs
demand
running
and
the
memory?
You
need
to
look
at
the
RSS
column,
so
it's
less
than
23
megabytes.
So
it's
very
very
low,
actually
CPU
usage
is
still
a
bit
High,
that's
gonna
improve,
but
so
so
far
it's
a
very
good
start.
I
think
it's.
It
shows
that
you
can
actually
have
a
full
node.
All
the
ground
is
that
you
get
from
a
full
node
running
on
a
mobile
device.
A
We
want
also
to
experiment
with
different
particular
topologies
different
configurations
around
that
it's
probably
okay,
to
do
mdns,
for
instance,
in
some
in
some
settings
and
and
not
DHD,
and
one
important
thing
that
we
want
to
know
what
kind
of
new
apis
we
have
to
expose
to
web
content
to
let
people
write
distributed
web
apps
very
easily,
so
the
the
first
step
here
is
to
be
able
to
get
and
post
content.
So
right
now
we
have
all
the
get
is
is
covered
by
the
protocol
and
layers
publishing
yeah.
A
That's
that's
what
what
move
did
in
aggregor?
We
we
need
to
discuss
to
agree
on
on
something
that
we
are
all
happy
with
the
and
there
are
other
other
things
like
peers,
Discovery,
API,
custom,
PHP
protocols.
I
know
that
that's
something
that
the
birdie
team
will
need.
If
we
wanted
to
do
a
part
of
Bertie
on
a
on
capirum,
there
may
be
some
other
apis
needed,
I'm,
I'm,
not
sure
which
ones
I'm
looking
for
inputs
from
App
developers.
So
if,
if
you
want
to
come
and
provide
inputs,
they
are
more
than
welcome.
A
Thank
you.
Another
thing
we're
going
to
work
on
as
as
a
web
native
file
systems
report,
so
one
notify
system.
It's
like
a
much
better,
unique
surface.
It's
it
supports
not
just
basic
hierarchical
storage,
but
there's
public
and
private
trees.
So
you
can,
you
can
share
stuff
privately
metadata,
versioning
Etc.
It's
mostly
worked
on
by
the
people
at
vision
and
what
we
plan
to
do
with
that
is
that
we
have
incaping
all
the
user
data
is
stored
in
in
a
virtual
file
system.
A
So,
like
all
the
user
media
contacts,
even
we
are
gonna
store,
yeah,
various
weather,
plugins
for
function,
image,
processing
and
things
like
that.
The
idea
is
that,
instead
of
only
storing
locally
and
doing
some
custom
backup,
we
can
publish
all
that
to
ipfs
through
our
winfs
and
it
it
meshes
well
with
iOS,
because
whenever
winfs
just
needs
a
block
store
as
an
external
API,
so
we're
gonna
hook
up
magnetic
file
system
with
iOS
box
store,
and
we
should.
We
should
get
a
fairly
complete
solution.
A
As
more
like
future
work,
something
that
I
really
like
to
explore
is
something
around
device:
convergence
using
ipfs
I'm,
all
very
often
in
situations
where
I
want
to
access
or
control
same
kind
of
data
from
different
devices.
Typically,
at
home,
you
have
laptop
a
phone,
a
media
center
connected
to
your
TV
and
it's
kind
of
cumbersome
to
get
all
that
work.
A
Well
together,
it
should
be
seen
as
kind
of
a
single
virtual
device
that,
as
I
says
through
your
data,
or
that
you
can
maybe
share
some
data
with
other
people
in
in
the
same
space
and
I
think
with
all
these
techniques,
we
can
get
to
something
that
just
works
in
in
a
very
seamless
way
and
and
very
privately
so
yeah,
something
it's
a
bit
further
thinking,
but
yeah.
We
we
should
try
to
do
something
around
that
guest
I
can
guest
access
with
few
cancels.
A
Also,
it
looks
fairly
a
very
good
use
case,
for
you
can,
where
someone
won't
access,
some
very
specific
subset
of
your
data.
It
is
something
we
can
do
and
yeah
that's
what
I
have.
Thank
you,
everyone
and,
if
you
want
to
see
it
running,
I
have
a
couple
of
devices
and
I
can
showcase.
The
networking
is
not
helping
much,
but
you
can
still
try.
Thank
you.