►
From YouTube: Architectural Collisions - Hard Problems on IPFS network By Dietrich Ayala @ Paris P2P Festival #1
Description
The Browsers & Platforms team at Protocol Labs works on IPFS integration across many deployment environments, with many different collaborators, on various architectures, including even the final frontier… SPACE! We’ll share a series of scenarios with examples of what worked, what didn’t, and what’s still in progress to give you a peek into the P2P future.
https://www.p2p.paris/festival
(CC BY-NC-SA 4.0)
Pour soutenir l'indépendance du festival, et sa gratuité :
https://p2p.paris/fr/donate/
_______________________
L’objectif de ce festival gratuit est de proposer 5 jours de rencontres autour de toutes les thématiques liées au Peer-to-Peer. Si la notion technologique du P2P est évidemment importante, elle est également un ensemble de valeurs, qui compose une philosophie.
Les valeurs du Peer-to-Peer peuvent s’appliquer à un très grand nombre de thématiques, comme la sécurité des communications, la protection de la vie privée, le partage de savoirs, mais aussi dans les arts, ou encore les échanges monétaires.
Le Paris P2P Festival se veut une occasion de fédérer et permettre la rencontre des acteurs du Peer-2-Peer sous toutes ses formes.
Toutes organisations portant des projets, tech ou non tech, se reconnaissant de ces valeurs sont donc les bienvenues à se joindre à cet événement pour y organiser leur propre rencontre, y poser un stand, ou organiser un hackathon.
Cet événement est le “prolongement” des rendez-vous mensuels de Paris P2P, tous les premiers mercredi du mois à Ground Control. Il représente l’ouverture d’un réseau de personnes, collectifs, associations, entreprises (…) souhaitant profiter ensemble d’un événement par et pour sa communauté, sans but lucratif.
A
Hey
everybody
thanks
for
joining
nice
to
see
you
all.
I
was
super
sad
to
not
make
the
last
one
of
these,
especially
well.
I
didn't
know
at
the
time
that
I
would
have
to
wait
a
couple
years
to
come
to
the
next
one.
So
hello,
my
name's
dietrich
ayala
and
I
work
at
protocol
labs
and
I
work
on
ipfs
related
things
and
I've
met
some
of
you
before,
maybe
all
the
way
back
to
ipfs
camp
and
some
of
you,
I
work
with
all
the
time
and
only
met
yesterday
or
even
today.
A
So
it's
really
great
to
be
here.
I've
been
working
on
ipvs
related
things
for
about
three
years
and
maybe
a
little
bit
more
and
before
that
I
worked
on
mozilla
firefox
the
browser
for
over
a
decade.
So
I
come
from
the
web
2
world
and
still
feel
kind
of
new
to
web3
things.
Today,
I'm
going
to
talk
about
a
little
bit
what
we
do
as
a
team.
I
work
on
the
browsers
and
platforms
team
and
we
do
things
like
put
ipfess
in
strange
places
with
some
of
the
people
here
today.
A
Here's
a
quick
look
at
what
we're
going
to
do
in
this
current
quarter,
some
of
the
stuff
I'm
going
to
talk
about
today,
but
also
a
bunch
of
things
that
we
do
with
other
people
and
other
projects,
a
lot
of
which
means
trying
to
get
things
like
p2p,
into
places
that
are
paradomatically
opposed,
sometimes
or
at
the
very
least,
not
at
all,
convenient
to
getting
things
like
ipfs,
actually
working
and
functioning.
Well.
A
But
these
are
a
number
of
different
problems
that
we
have
when
trying
to
get
things
like
ipfs,
which
is
highly
dependent
on
an
underlying
network
architecture,
infrastructure
that
doesn't
work
the
way
that
http
works
into
some
of
these
places
with
some
of
the
projects
and
partners
that
we
work
with
all
the
time.
This
goes
from
security
and
privacy
models
that
are
very
strict
for
good
reasons
in
things
like
web
browsers.
A
As
you
get
closer
towards
the
context
of
a
given
use
case
or
where
people
are
using
ipfs-based
applications-
and
I
think
that
makes
that
paradomatic
difference
between
this
and
this
incredibly
difficult
when
you're
trying
to
do
things
like
mobile
applications,
browser
integrations
and
all
the
other
places
that
we
want
to
be
able
to
see
these
technologies.
So
I'm
going
to
talk
about
a
couple
of
these
strange
places
where
we've
had
hard
problems
getting
ipfs
into
it.
A
So
here's
like
a
a
a
sadly,
mostly
red,
but
oddly
inspiringly
green
kind
of
look
at
top
browsers
and
where
we
have
ipfs
related
technologies
or
at
least
have
conversations,
and
I
think,
when
you're
building
your
own
application
a
lot
of
times
you're
like
I'm,
going
to
use
ipfs
or
I'm
going
to
use
this
other
technology,
I'm
going
to
use
something
else.
But
when
it
comes
to
things
like
browser
integrations,
we
actually
have
to
get
the
buy-in
of
people
that
are
building
applications
for
hundreds
of
millions
and
sometimes
even
billions
of
people.
A
So
sometimes
something
like
a
publicly
positive
mention
really
goes
a
long
way
and
itself
is
even
a
huge
victory
in
the
very
long
road
towards
long-term
integration.
Adoption
of
some
of
these
technologies.
Sometimes
we
have
privately
positive
comments
from
partners
or
people
that
we're
talking
to
at
browsers
that
I
won't
say
names
out
loud
but
may
be
familiar
to
you
and
are
interestingly
immutable
to
implementing
something
like
ipfs.
A
These
can
be
interesting
and
long
conversations.
One
of
the
one
of
the
groups
of
people
who
are
it's
not
awkward
and
is
awesome
to
work
with
them
is
brave,
so
they
were
the
first
browser
to
do
a
full.
The
first
browser
with,
like
you,
know
millions
of
users
to
do
a
full
integration
of
ipfs,
where
they
added
support
for
the
ipfs
and
ips
schemes.
You
can
actually
load
a
full
ipfs
node
from
within
brave
when
you
go
to
an
ipfs
address
that
prompts
you
to
do
some
of
these
features.
A
They
bundled
ipfs
companions
super
early,
it's
fantastic
to
work
with
them,
but
there
are
a
lot
of
unsold
problems,
so
adding
an
ipfs
node
to
something
like
a
browser
uncovered
all
these
other
things
that
you
have
to
do
when
you're
a
browser,
and
you
need
to
communicate
things
to
users,
things
especially
things
about
trust.
So
how
do
you
visualize?
How
connected
your
ipfs
node
is?
Well,
we
learned
earlier
today
that
either
you,
even
if
you
try
to
estimate
that
you're
going
to
be
wrong.
A
You
may
be
wrong
for
any
given
piece
of
content
that
you
don't
know
how
many
people
are
providing
it
or
if
they
actually
are
or
if
you
can
connect
to
them.
Well,
not
punching
we'll
help,
maybe
a
little
bit
with
that.
What
the
system
resource
use,
resource
usage
things
like.
How
do
you
communicate
like
with
ssl
in
the
browser
you
use
the
lock,
but-
and
that
gives
you
more
information
and
you
can
get
more
information
from
the
certificate
about
whether
you
should
trust
the
entity
that
you're
loading
a
web
page
from.
A
But
when
you
are
loading
a
cid?
What
does
trust
me
and
where
do
you
get
that
trust?
Is
it
out
of
band?
There's
no
certificate
really
that
you
can
get
single
business
entity,
information
from
or
anything
like
that,
where's,
your
stuff,
you
can
load
a
bunch
of
stuff
in
brave
over
ipfs,
but
how
do
you
get
to
the
node?
There's
not
really
a
way
to
visualize
it.
A
So
a
lot
of
new
things
that
we
still
have
to
figure
out
when
thinking
about
what
ipvs
means
in
the
hands
of
regular
people
at
scale
chromium
to
visualize
to
scale
here.
We're
working
with
a
company
called
galia
and
they've
been
doing
web
consulting
for
over
20
years.
They
have
commit
privileges
to
gecko,
webkit
and
and
chromium,
and
we
work
with
them
to
be
able
to
fix
initially
fixing
like
browser
compatibility
issues
so
with
when
you
have
a
ipfs
web
app
that
you
want
to
load
from
a
local
node.
A
We
needed
to
make
sure
that
the
local
host
handling
from
a
security
perspective
and
a
capability
perspective
in
browsers
was
consistent.
So
we
were
working
with
the
galia
to
fix
some
of
the
issues
around
there
and
actually
make
kind
of
like
not
just
for
ipfs
but
make
localhost
node
development
patterns
for
decentralized
projects
easier
for
everybody
and
now
we're
working
with
them
to
refactor
chromium,
to
basically
add
better
support
for
non-hdp
http
protocols,
so
chromium
if
you've
ever
looked
through
the
source
code.
It's
a
massive
massive
project.
A
It's
a
universe
of
different
companies,
different
use
cases,
there's
lots
of
embedders
of
it
chromium-based
browsers,
but
also
other
things,
and
all
of
that
code
base
is
pretty
http
blinders
on
and
all
the
way
up
and
down
the
security
stack.
The
permission
stack.
The
network
stack,
which
runs
an
entirely
separate,
separate
process,
there's
a
whole
lot
there.
That
needs
to
be
done
just
to
be
able
to
add
support
for
something
that
is
not
http,
let
alone
ipfs.
So
this
is
work.
A
That's
been
going
on
for
at
least
over
a
year
for
just
this
refactor
many
many
many
conversations
of
patches
and
basically
every
time
they
do
a
refactor
and
they
actually
get
some
significant
pieces
done.
They
uncover
yet
more
of
the
chromium
code
base.
That
needs
to
be
converted
to
be
able
to
basically
handle
anything.
That's
not
hd
http,
so
this
actually
benefits
not
just
ipfs
and
lupita
p,
but
also
any
decentralized
protocol
that
or
any
non
hdd
pro
protocol,
really
that
you
want
to
add
into
chromium.
A
But
when
you're
a
browser
vendor
actually
adding
something
like
a
go,
ipfs
node
is
kind
of
untenable
out
of
the
gate
for
a
lot
of
different
reasons
from
security
standpoint
to
like
just
knowing
what
the
software
is
doing.
Brave
is
doing
some
amazing
things
and
experimenting
with
that
and
we're
learning
a
lot.
But
looking
at
the
long-term
architecture
of
native
ipfs
and
browsers,
we
have
to
kind
of
reevaluate
that
node-oriented
model
we're
doing
a
lot
of
stuff
with
browser
extensions
which
has
become
problematic.
A
One
of
the
big
challenges
that
we
have
right
now
is
we
had
to
rewrite
ipfs
companion
for
what's
called
manifest.
V3,
google
has
decided
to
re-architect
how
browser
extensions
work
for
somewhat
good
reasons:
performance
related
security,
related
user
safety
related,
but
it
also
radically
reduced
the
surface
area
of
features
that
you
have
as
an
extension
developer,
which
meant
that
we
can
no
longer
do
a
lot
of
the
things
that
we
did
in
rpfs
companion
before,
and
we
have
to
rethink
what
the
ipfs
extension
will
actually
do.
A
We
kind
of
thought
initially
that
it
would
be
on
the
road
to
eventually
implementing
ipfs
in
browsers,
but
that
door
is
pretty
much
shut
with
manifest
v3
and
it's
not
really
going
to
be
possible,
so
we're
trying
to
think
what
we
need
to
do
there.
We
already
have
our
rewrite
of
ibfs
companion
done,
but
there's
a
lot
of
other
stuff
that
needs
to
happen
there
and
actually
google's
running
pretty
behind
on
this
shift.
Anyway.
Mobile
is
another
area
where
ibfs
doesn't
really
fit
well
with
the
network
architecture
of
these
devices.
A
However,
we
kind
of
have
this
like
square
peg
round
hole
problem
again,
where
you
have
a
design
of
the
implementation
of
ipfs,
which
doesn't
align
well
with
the
architecture
of
the
devices
it's
running
on
and
connectivity
becomes
really
hard
when
that
happens.
So
not
only
is
it
not
natively
integrated
kind
of
into
the
os
sdks,
but
also
has
a
device
kind
of
weight,
both
in
cpu
battery
bandwidth
that
doesn't
align
well
with
common
mobile
use
cases.
A
Durin
is
a
new
project
that
we
started
this
year
for
native
ios
and
android
applications
that
are
basic
use
cases.
So
it's
going
to
enable
basic
sharing
like
how
can
I
just
share
an
image
to
ipfs,
or
can
I
download
an
image
or
an
image?
That's
already
on
my
device
and
add
it
to
my
to
my
ipfs
somewhere
more
of
an
experimentation
platform.
At
this
point,
we're
going
to
add
some
features
like
being
able
to
send
all
your
photos
up
to
nft,
storage
or
web3.storage.
A
Things
like
that
save
them
to
filecoin,
integrate
with
remote
pinning
services,
be
able
to
see
the
list
of
images
that
you've
that
you've
shared
that
you've
shared
or
that
you've
saved,
and
things
like
that.
But
again,
there's
not
really
a
kind
of
like
way
that
ipfs
fits
neatly
into
how
you
think
about
mobile
use
cases
at
the
operating
system
level.
So
when
you
save
to
ipfs,
which
ipfs
does
it
save
too
again
kind
of
like?
A
Where
is
my
stuff
problem
at
the
application
layer
of
working
with
ipfs,
but
also
when
you
want
to
publish
to
ipfs,
if
you
don't
have
say
an
account
with
some
service,
that's
going
to
host
and
persist
your
stuff.
Where
are
you
sharing
to
so
there
are
these
flows
that
we
need
for
regular
users
to
be
able
to
you
like
save
and
load
from
ipfs
all
day
every
day,
with
the
things
that
we
all
do,
that
have
to
be
figured
out
at
the
operating
system
level.
Things
like
even
things
like.
Where
do
your
photos
go?
A
So,
do
you
keep
a
full
copy
of
the
photos
when
you
add
it
to
ipfs
locally?
Do
you
save
it
to
your
photo
role
in
the
operating
system?
Should
we
have
integration
of
things
like
a
local
ipfs
data
store
that
exposes
itself
the
way
that
some
applications
do
into
the
local
photo
role?
Lots
of
stuff
like
that
to
figure
out
the
application
layer
that
would
make
it
easier
to
work
with
ipfs
agrigore
is
an
application.
It's
a
browser
that
was
designed
to
be
multi-protocol
from
the
beginning,
so
it
had
dat
bindings.
A
It
had
ipfs
support
and
things
like
that.
We
just
started
a
new
grant
with
them
they're
working
with
some
folks,
basically,
some
mesh
networking
folks
in
south
africa
to
design
a
mobile
version
of
aggregor.
That's
a
rebuild
of
chromium,
but
with
ipfs
added
and
with
kind
of
an
application
model
built
on
this
mesh
networking
capability,
that's
going
to
be
super
interesting.
They
have
gotten
pretty
far
actually
and
in
this
challenges
section
I
was
going
to
talk
about
what
they
did,
but
they
just
published
a
blog
post
yesterday
or
the
day
before.
A
That's
all
of
the
challenges
that
they've
had
so
far
in
trying
to
actually
kind
of
recompile
chromium,
but
for
android,
but
with
alternative
protocol
like
ipfs
in
there
it's
a
super
interesting
read,
and
it
really
gives
you
a
view
into
how
difficult
it
is
from
an
engineering
standpoint
to
take
these
things
that
were
really
built
for
ipfs
or
for
http.
Only
and
add
things
like
ipfs
to
them,
especially
in
really
constrained
environments
like
like
mobile
and
especially
when
the
like
source
code
base,
like
things
like
chromium,
are
fairly
complex.
A
So
a
lot
of
it
is
wrestling
with
build
systems,
and
things
like
that.
Capulene
is
a
mobile
operating
system,
which
I
have
one
of
these
phones
with
me.
If
you
want
to
check
it
out,
I've
flashed
it
to
a
pixel
3.
So
we
can
try
it,
but
this
is
basically
the
kaios
operating
system
which
was
based
on
the
firefox
os
operating
system.
From
that
you
may
remember
from
five
ten
years
ago,
I
was
a
project
lead
on
firefox
os
and
got
it
shipped
on
a
whole
bunch
of
phones.
A
So
I'm
pretty
familiar
with
kind
of
the
core
architecture
and
how
to
how
to
do
this,
and
some
of
these
folks
from
kaios
wanted
to
do
some
experiments
with
web3
technologies.
So
we
gave
them
a
grant
to
be
able
to
add
ipfs
and
file
coin
support
to
capulin.
So
today
you
can
take
an
image:
that's
a
gsi
for
android
phones,
so
it
runs
on
basically
anything
any
device
that
supports.
A
Out
of
the
box,
has
metamask
bundled
with
it,
and
we're
going
to
be
able
to
use
that
as
an
experimentation
platform
for
what
a
native
web
3
operating
system
might
look
like.
That's
also
web
native
operating
system,
so
not
based
on
ios
or
android,
really
interesting
from
an
experimentation
factor.
There's
lots
of
lots
of
projects
that
we're
going
to
talk
to
that.
A
They
want
to
try
this
out
as
the
base
for
their
mobile
operating
system
or
for
at
least
what
I'm
reimagining
kind
of
what
a
mobile
operating
system
world
could
look
like
when
it's
kind
of
with
our
values
defined
for
the
people
that
are
at
an
event
like
this.
So
that's
pretty
exciting
and
those
images
are
available
right
now
at
capylon.org,
even
the
images
are
being
distributed
on
ipfs,
but
some
of
the
challenges
are
using
a
kind
of
daily
driver.
A
Ipfs
based
operating
system
found
out
all
kinds
of
bugs
already
in
our
gateway
implementation
and
some
of
the
persistent
services
that
we've
implemented.
So
it's
been
great
to
be
able
to
get
that
feedback
once
you
start
doing,
experiments
like
this
that,
like
kind
of
like
going
all
the
way
with
ipfs,
you
start
finding
issues
that
affect
everybody
and
we've
found
it
fixed
already
a
couple,
so
the
value
of
that
has
pretty
great,
been
pretty
great.
A
So
far,
some
of
the
other
places
where
we're
putting
ipfs
where
it
doesn't
quite
fit
nearly
or
neatly,
are
different,
open
source
tools
that
you
might
be
familiar
with
so
mark
geyser
who's.
We're
here
has
been
working
on
and
actually
just
recently
got
landed.
Congratulations
mark
support
for
ipfs
in
ffmpeg,
so
this
means
that
ipfs
can
be
available
inside
media
tools.
All
different
types
of
like
tv
and
entertainment
stacks
ffmpeg
is
used
in
so
many
different
places.
So
the
ability
to
have
ipfs
be
a
default
available.
A
Loaded
data
source
for
fmpeg
is
really
important,
started
out
as
a
grant
and
after
a
very
long
typical,
open
source
negotiation
with
ffbeg
and
the
community,
there
actually
got
it
landed
and
it
will
ship
in
the
next
version,
which
is
super
very
cool.
Some
of
the
challenges
that
we
found
were
like:
how
do
you
configure
ipfs
gateway
defaults
without
just
always
going
to
ipfs.io?
A
A
There
is
no
kind
of
like
idiomatic
ipfs,
it's
a
toolkit
for
building
things
like
this,
and
so
it's
been
an
interesting
conversation
around
how
what
does
ipfs
integration.
That
is
something
like
chrome
look
like
when
it's
not
supported
in
the
operating
system.
You
have
to
do
a
lot
of
work
at
the
tool
level
at
the
library
level
to
kind
of
define
what
the
behavior
is
going
to
be,
and
it's
not
going
to
work
out
of
the
box
for
everybody
and
for
every
use
case.
A
So
it's
been
really
interesting
to
walk
through
the
implementation
of
these
tools
and
there's
still
a
lot
of
work
yet
to
go
on
this
one
in
particular
another
area
where
we're
trying
to
get
things
like
hpfs
in
and
it's
not
really
easy-
is
into
operating
system
file
explorer.
So
things
like
windows,
explorer
or
finder,
and
whatever
your
links,
distribution
file
explorer,
is
the
same
guy
who's,
working
on
fmpeg
and
whip
and
or
webdav,
and
the
cruel
support
mark
is
here
today
and
he's
also
working
on
this
web
integration.
A
A
Do
some
development
there
and
see
what
we
can
actually
make
happen
and,
as
you
can
see
here,
mark
did
get
a
hacky
prototype
of
this
working,
so
we're
investigating
what
the
road
forward
is
kind
of
to
be
able
to
get
that
working
better
and
more
usable
iot
is
another
one.
Ipv's
tiny
is
an
implementation
of
a
subset
of
pieces
of
ipfs
and
c-plus
plus
designed
for
embedded
software
and
microcontrollers.
A
They
have
some
of
the
basic
pieces
working.
I
think
ipld
just
got
finished,
there's
some
ipva
c
plus
out
there,
but
it
wasn't
really
fully
completed
and
not
totally
usable.
So
hopefully
this
will
be
a
more
usable
implementation
with
a
open
source
community
behind
it.
The
folks
from
librespace
who
I'll
talk
about
in
a
second
are
doing
a
lot
of
this
work.
A
But
it's
been
interesting
and
difficult
because,
again,
like
the
network
architecture
of
a
lot
of
these
devices
means
and
the
constraints
the
type
of
transports
you
have
available
mean
you
can't
get
a
fully
pdp
stack,
so
you
kind
of
have
to
reimagine.
How
does
the?
How
does
the
communication
topology
of
ipfs
work
when
you
might
have
a
bunch
of
sensors
that
are
emitting
data
that
may
be
phone
home
to
a
central,
a
centralized
gateway?
That
then
provides
that
data
to
the
broader
ipfs
network?
Or
you
have
things
like
broadcasted
sensor
data?
A
You
have
somebody
just
harvesting
all
this
broadcast
data
and
making
that
content
address
data
available
to
the
network.
So
we've
been
doing
a
lot
of
experimentation
there,
trying
to
figure
out
how
that's
going
to
work
space
ipfs
in
space,
so
the
people
that
did
that
previous
implementation
also
launched
satellites,
they're,
an
open
source
space
group
from
greece
and
they're
working
on
adding
ipfs
into
one
of
their
satellite
launches.
Hopefully,
that's
going
to
happen
either
end
of
this
year
or
the
beginning
of
next
year,
there's
been
a
long-running
grant
that
we've
had
with
them.
A
You
can
go
to
are
we
interplanetary
yet.org
and
keep
an
eye
on
whether
or
not
ipfest
is
in
space?
Yet
I
think
I
had
a
whole
section.
I
mean
this
could
be
a
much
much
longer
talk
and
I
kind
of
did
the
speed
run
through
it
happy
to
answer
any
questions
that
people
have
about
these
projects
and
and
talk
with
you
about
it
for
I'll,
be
here
all
day
tomorrow
as
well,
and
the
there's
a
whole
area
of
metaverse
that
is
kind
of
ill-defined.
A
It's
not
really
clear
how
ipfs
and
nfts
and
all
these
other
p2p
technologies
fit
into
it.
We're
working
with
a
lot
of
these
projects,
and
we
have
ideas
why
we
think
things
like
content
address.
Data
will
be
very,
very
important
in
an
open
standards
and
interoperable
approach
towards
metaverse
or
even
just
basic,
like
webxr
use.
A
Cases
and
implementations
integrations
we're
talking
with
some
of
the
browsers
that
have
implemented
webxr
to
be
able
to
have,
and
some
of
the
toolkits
too
things
like
a-frame
to
be
able
to
add
better
support
for
content,
address
data
and
ipfs
data
into
the
development
experience
for
for
that
kind
of
stuff.
But
it's
not
quite
there
yet.
So
I
think,
there's,
maybe
maybe
next
year
I'll
come
back
and
talk
about
the
stuff
that
hopefully
we
have
done
in
there
since
then.
But
that's
it.
B
We
have
hi
thanks
for
the
talk
you
briefly
touched
on
this,
but
what
is
the
general
feeling
about
whether
support
for
ipfs
needs
to
be
at
the
operating
system
level?
Right
applications
don't
have
to
do
their
own
dns
lookups.
They
just
hand
that
to
the
operating
system
and
because
also,
if
you
have
multiple
applications
on
a
machine
doing
ipfs,
you
don't
want
each
of
them
to
have
to
be
running
a
node.
B
A
So,
like
you
said
like
it's
a
pretty
basic
challenge,
if
ipfs
adoption
starts
to
grow,
you
get
one
ipfs
node
on
your
computer
and
then
you
get
two
ipfs
nodes
on
it
and
that
problem
can
grow
really
fast,
especially
if
each
one
of
those
nodes
is
one
like
taking
up
disk
space
running
taking
using
cpu,
but
then
also
opening
up
hundreds
of
tcp
sockets
too.
So
that's
a
serious
problem
that
we
have
to
figure
out
with
adoption.
A
That
has
happened
at
the
operating
system
level.
For
for
this
to
really
really
grow
in
scale.
Where,
like
you
have
many
many
hundreds
of
applications
running
on
your
system
that
are
all
using
ipfs
and
and
network
is
just
one
problem
and
system
resource
usage,
but
also
like
data
sharding
like
right
now.
Your
ipfs
repo
is
just
one
giant
kind
of
global
space
of
data
and
that's
not
really
functional
for
a
lot
of
different
types
of
applications.
So
I
do
think
operating
system
support.
D
Hi,
so
you
mentioned
that
the
liver
that
space
are
using
the
c
c,
plus
plus
implementation
of
the
peer-to-peer.
I
understand
that
it
was
a
like
four
years
ago,
when
rust
kind
of
wasn't
a
big
thing,
but
currently
the
embedded
rest
space
is
pretty
big.
Now
and
I
would
say
it's
like
somewhat
safe
to
rely
on
it.
So
do
you
know
some
of
their
thoughts
or
potentially
for
getting
rust
liberty.
A
A
Why
not
do
rus
from
the
beginning
and
the
folks
that
are
working
on
so
liberty
and
space
are
actually
writing
that
implementation
in
cpus
plus,
and
one
of
the
reasons
why
they're
doing
that
is
because,
while
the
embedded
rest
space
is
growing,
the
embedded
space
as
a
whole
is
very,
very
slow
to
change
and
very
resistant,
especially
to
to
to
changing
at
that
scale.
And
so
the
advice
was
all
right
or
the
kind
of
the
decision
there
was
we're.
A
Gonna
need
both
for
probably
five
to
ten
years,
and
while
rust,
embedded
space
continues
to
grow
and
mature
new
devices
are
coming
online
that
are
friendly
to
us
and
have
really
happy
to
be
able
to
have
that
choice
can
take
advantage
of
rust,
ipvs
implementations
and
rustler
pdp
implementations
as
they
mature,
but
for
a
lot
of
devices.
If
we
want
ipfs
capabilities
to
be
available
today
for
those
devices,
we
need
to
have
a
c
plus
implementation
that
they
can
choose.
So
it
really
was
a
pragmatic
decision
around
well.
A
Every
internet
connected
device
is
gonna,
be
embedded,
embedded,
anyways
c
plus
plus
at
this
point,
so
that
was
a
very
practical
decision
that
we
hopefully
at
least
get
us
a
few
years,
if
not
more
of
usage
and
probably
a
long
tail
much
longer
than
that,
whereas
as
rust
usage
grows,
we
can
encourage
new
users
and
devices
who
are
open
to
making
that
decision
to
do
so.
Thank
you.
Yeah.