►
Description
Lessons from putting IPFS in weird places - presented by Dietrich Ayala at IPFS bing 2022 - IPFS Implementations - https://2022.ipfs-thing.io
A
Hey
so
I'm
dietrich,
I
work
on
browsers
and
platforms.
I
work
with
probably
a
significant
number
of
the
people
in
this
room,
based
on
all
the
handshaking
and
hugs
and
stuff
today
and
yesterday
and
meeting
a
bunch
of
people
for
the
first
time
in
real
life,
which
has
been
great
one
of
the
things,
and
one
of
the
reasons
why
I
end
up
working
with
you.
A
So
I'm
going
to
talk
today
a
little
bit
about
some
of
those
projects,
some
of
those
relationships,
some
of
the
problems
that
we've
encountered
and
some
of
the
directions
that
I
think
is
really
really
important
for
us
to
be
able
to
go,
especially
given
the
group
of
people
that
we
have
in
this
room.
So
we
work
a
lot
in
putting
ipfs
in
strange
places
on
the
browsers
and
platforms
team.
Honestly
like
these
really
aren't
that
strange.
These
are
kind
of
the
places
where
software
is
so
or
was
so.
A
These
aren't
really
that
strange
places.
These
are
all
the
places
that
ipv6
needs
to
be
should
be
actually
is
most
of
the
time
where
it
functions.
Sometimes
these
are
some
of
the
groups,
and
maybe
this
is
where
it
gets
a
little
weird
right,
so
we're
working
with
you
know
directly
with
badger
from
girl
we're
also
working
with
groups.
Like
lockheed
martin,
announced
a
recent
space
collaboration.
A
We
work
in
chromium
slowly
but
surely,
and
with
some
of
the
groups
here
like
agrigore,
and
we
also
work
with
groups
like
agalia
to
be
able
to
get.
You
know
some
of
the
web
standards
fixed
across
the
entire
web
platform
itself.
We've
made
some
progress
in
browser
world
there's
more
green
here
than
I
probably
would
have
expected,
but
there's
still
really
a
lot
of
ways
to
go
for
various
numbers
of
reasons.
A
A
We
have
browser
extensions
across
all
the
major
browsers,
mostly,
but
with
the
advent
of
manifest
v3
that
world's
going
to
change
we're
going
to
be
able
to
do
even
less
before
than
we
could
before
and
with
groups
like
birdie,
really
supporting
their
efforts
and
figuring
out
what
mobile
story
really
looks
like
fabrice
from
kapiloon
is
here,
where
we've
been
experimenting
with,
what
a
web-based
mobile
operating
system
looks
like,
and
some
of
the
challenges
there
and
dave
justice
is
here
and
some
of
the
folks
from
trigram
couldn't
join,
but
they've
been
working
on
durian,
which
is
a
mobile
operating
system
or
sorry,
a
mobile
app
that's
available
on
the
ios
app
store.
A
As
of
I
think,
two
days
ago,
that's
experimenting
with
what
a
platform
aligned
version
of
ipfs
services
on
ios
might
look
like
being
able
to
share,
publish
integrate
your
photo
role
and
things
like
that
and
agrigore,
which
is
really
doing
interesting
things
around
multi-protocol
browsing
and
also
some
experiments
around
what
a
deeper
integration
of
ipfs
and
web
apis
would
look
like,
so
be
able
to
use
the
fetch
api
to
be
able
to
post,
to
an
ips
name
or
to
a
cid.
For
example.
A
Some
of
the
challenges
are
not
going
to
be
surprising.
You
know
the
language
that
developers
are
using
sometimes
isn't
available.
The
folks
at
capsule
social
wanted
to
do
things
that
we
hadn't
quite
done
yet
with
in
the
js
world.
Beam
wanted
basic,
like
node
syncing,
between
two
nodes
to
be
able
to
work
kind
of
out
of
the
box,
also
with
js,
and
you
know
some
of
the
even
bigger
partners
that
we
have
and
the
folks
that
we
talk
with,
like
ledger,
really
were
like
some
of
the
basic
fetching
stuff
they
wanted
to
do.
A
Wasn't
working
some
of
the
other
projects
that
that
you
know
we
work
with.
Have
some
of
these
problems
where,
depending
what
their
environment
is,
the
type
of
data,
sometimes
the
shape
of
the
data
network
availability,
doesn't
actually
function
in
the
right
way?
You
know,
folks,
like
you
know,
badger
were
like
where's
where's,
the
spec,
and
they
couldn't
actually
figure
out
where
the
spec
was
and
we'd
be
able
to
understand
what
the
component
parts
of
ipfs
were
in
order
to
figure
out
how
they
could
reasonably
implement
it.
A
Some
of
the
standards
bodies
work
that
we
do
they
ask
for
like.
Okay,
where
is
that
spec
and
what
standard
body
is
this
kind
of
technology
blessed
under
and
that's
a
pretty
significant
barrier
to
adoption
for
in
a
number
of
ways,
some
of
the
folks,
like
tbd,
they're,
figuring
out
what
this
new
distributed
web
node
stack
that
they're
building
looks
like
they
need
it
to
work
in
multiple
runtimes,
but
there's
not
really
a
clear
definition
of
what
ipfs
is
and
what
it
means
on
the
different
runtimes
where
they
need
it
to
work.
A
A
You
know
kind
of
have
our
religion
today
around
some
of
these
technologies,
the
characteristics
some
of
the
failings
of
existing
systems,
and
how
do
we
get
ipfs
into
the
hands
of
more
people,
so
they
can
benefit
from
what
it
actually
brings
and
the
gaps
that
it
closes
and
the
places
like
the
web
platform
today
or
cloud
or
data
availability,
or
even
censorship,
mitigation
and
stuff
like
that.
A
But
I
think
one
of
the
most
important
parts
for
me
that
I've
learned
over
a
couple
of
years
of
working
with
people
where
sometimes
ipfs
isn't
working
for
them
is
that
it's
not
clear
often
what
it
actually
is
that
there's
a
lot
of
code
and
there's
a
lot
of
different
things
that
you
can
do.
It
is
a
toolbox
for
building
decentralized
and
distributed
applications.
A
But
at
its
kernel
it's
not
there's
not
one
thing
to
be
able
to
point
at
like
a
minimally
viable
implementation,
and
so
what
does
it
mean
to
be?
Ipfs
is
not
really
clear,
and
that's
one
of
the
reasons
why
we're
all
here,
because
it
does
mean
a
bunch
of
different
things
to
a
bunch
of
different
people.
There
are
various
use
cases
that
aswan
talked
about
pull,
go
ipfs
in
different
directions,
and
that
was
really
challenging
and
needs
to
go
to
a
lot
of
places
and
maybe
also
like
he
said
it
just
starts
with
using
cids.
A
But
unless
we
actually
can
all
kind
of
come
to
an
agreement
about
what
that
means,
we
can
actually
get
a
protocol
ipfs
as
a
protocol
to
where
it
needs
to
be,
which
is
available
in
a
bunch
of
different
contexts.
These.
What
should
not
be
strange
places
available
in
many
programming
languages,
like
you
know,
there's
some
folks
here
from
algebra
that
are
doing
a
grant
working
on
extending
python
functionality
and
maybe
even
implementing
ipfs
and
python,
because,
as
the
I
think,
I
was
recently
now.
A
A
So
this
is
one
proposal
which
is
at
least
you
know
at
some
point,
get
to
an
agreement
as
a
community
of
implementers
practitioners.
Users.
Builders
on
what
a
minimally
viable
definition
of
ips
would
be
ipfs
would
be,
and
that'll
get
us
like,
probably
too
much
more
solid
ground,
even
if
it's
just
as
simple
as
this
using
cids
that
we
can
communicate
to
a
much
larger
group
of
developers
of
builders,
stakeholders,
investors,
business
people,
building,
businesses
on
top
of
these
technologies.
One
quick
side
note
on
interoperability
and
how
important
it
is.
A
The
developers
needs
assessment
for
the
web
was
originally
started
at
mozilla
and
is
now
run
by
google
and
microsoft
and
now
has
run
for
a
few
years
and
they
use
mdn
as
a
way
to
get
this
survey
in
front
of
developers
and
it's
so
it's
probably
one
of
the
largest
surveys
of
web
developers,
which
is
the
largest
subgroup
of
developers
on
the
planet,
and
the
number
one
thing
that
they
found
is
still
today
still
today,
even
with
much
more
interoperable
web
runtimes
and
engines
number
one
problem
is
interoperability.
Compatibility
things
not
working.
A
What
we
can
learn
from
to
really
really
get
ahead
ahead
of
where
it
took
them
so
long
to
be,
is
to
adopt
some
of
these
learnings
into
how
we
build
ipfs
and
as
you're
building
out
your
new
implementations
think
about
how
you
can
use
a
shared
understanding
of
what
ipfs
is,
even
if
it's
at
a
very
minimal
level
shared,
maybe
even
shared
language,
or
to
be
able
to
get
maybe
close,
that
and
and
and
get
this
level
of
adoption
interoperability
and
make
it.
A
So
compatibility
is
not
such
a
problem
in
five
years
or
10
years,
as
opposed
to
30
years
on
the
web.
Today,
I
think,
would
you
get
down
to
that?
Small
of
an
idea
of
what
ipfs
might
be
is
it
still
ipfs,
not
something
that
as
implementers,
you
get
to
have
some
decision
making
about
right.
You
control
that
you're
gonna
be
making
trade-offs
in
every
place
that
you
ship
ipfs.
A
You
get
to
determine
whether
you
know
that
implementation
swings
towards
one
end
or
the
other
of
any
of
these
or
a
number
of
other
factors
that
you
need
to
take
into
consideration.
But
I
think
you
know
a
couple
of
closing
learnings
things
that
we
came
out
with,
like
it's
got
to
just
work.
Your
implementation
for
the
target
environment
like
a
general
purpose,
ipfs,
we
kind
of
found
the
limits
of
and
wong
talked
a
little
bit
about
that
earlier.
A
Where
go
ipfs
started,
getting
pulled
in
different
directions
and
made
it
really
difficult
for
us
to
meet
the
needs,
especially
when
environments
like
mobile
in
particular,
have
an
entirely
different
network
architecture
and
operating
model
that
has
strong
dependencies
up
and
down:
hardware
manufacturers
and
telcos
and
actual
radios,
and
all
these
other
things
that
that
really
dictate
how
the
the
protocol
has
to
actually
function.
A
And
if
we
can't
do
that,
and
if
you
can't
do
that
for
your
implementation,
understanding
deeply,
who
your
host
environment,
what
your
host
environment
is
and
what
those
developers
need,
then
they're
going
to
abandon
the
implementation.
I
think
another
lesson
is
it's
okay
to
throw
away
parts
of
ipfs
that
aren't
working
for
you?
If
you
reduce
the
idea
of
ipfs
into
well,
is
it
using
content
address
data?
Is
it
using
cic
ids
do?
Do
you
always
need
a
full
of
b2b
stack?
Maybe
not?
A
Maybe
it
doesn't
have
maybe
you're
just
working
with
data
directly
for
the
regular
web.
Well,
what
we
call
leech
mode
in
ipfs
network
is
kind
of
just
how
people
use
the
web
every
day
all
day,
billions
of
people,
maybe
that's
okay,
and
in
a
bunch
of
circumstances
and
finally
like
we
need
to
as
a
community,
be
able
to
make
clear
what
ipfs
actually
means,
and
that
doesn't
mean
up
and
down
an
entire
stack.
It
doesn't
mean
the
entire
every
edge
in
the
contrary
of
every
specification.
A
Every
possible
thing
like
this
could
do,
but
having
a
shared
understanding
of
what
the
basic
parts
mean,
what
those
basic
components
are,
what
are
the
minimum
viable
requirements
to
be
able
to
something
that
you
can
call
ipfs
is
really
important
and,
and
that
helps
adopters
reason
about
what
trade-offs
they're
making
it
helps
them
understand.
What
bits
are
are
not
composable
and
what
can
they
build
on
and
it
ultimately
means
what
the
benefits
are
to
them
and
how
they
can
continue
building
and
actually
trying
to
solve
that
thing.
A
They're
trying
to
solve
that
ipfs,
we
want
to
be
the
easiest
way
to
get
there.
But,
as
we've
learned
often
times
then
has
not-
and
I
think
you
know
this
week-
we
have
an
opportunity
to,
as
a
community
start
pushing
really
hard
on.
You
know,
building
the
implementations
for
the
platforms
that
we're
working
on
for
the
constituent
stakeholders,
developer
audiences
and
businesses
that
are
trying
to
build
on
it.