►
Description
In this May 2022 IPFS implementations workshop, we heard a number of first-hand accounts from builders & thinkers working on and with IPFS, taking stock of the current implementation story, and imagining what’s possible through shared effort on a protocol with such broad applicability.
A
Hey
everybody
really
thanks
brendan
for
setting
up
this
day,
super
important
conversation.
It
is
something
as
you
will
find
out
in
this
set
of
things
that
I
will
share
with.
You
is
something
that
affects
me
and
my
team's
ability
to
do
our
jobs
every
single
day.
So,
if
I
don't
know
you
even
I
know
most
of
the
people
here,
my
name
is
dietrich.
I've
been
working
on.
A
I,
professor
related
things
for
three
plus
years
now,
and
maybe
a
little
bit
before
that
worked
on
browsers
for
a
long
time
before
coming
over
into
this
wonderful
distributed
web
3
world,
and
I
lead
the
browsers
and
platforms
team
at
outer
core
protocol
labs
and
here's
a
sampling
of
some
of
the
things
that
we're
doing
this
quarter.
A
As
you
can
see,
we
work
across
a
number
of
different
areas,
but
the
common
denominator
is
really
that
we
put
ipfs
into
strange
places
where
it
is
currently
not
and
that's
everything
from
browser
integrations
to
different
mobile
use
cases.
A
lot
of
grants
like
we'll
talk
a
little
bit
about
move
and
the
work
that
you
saw
earlier.
A
Why
that's
important,
as
well
as
things
like
open
source,
tooling
operating
systems
and
use
cases
like
space,
metaverse
and
iot,
so
lots
of
places
that
I
think
I
would
consider
them
hostile
environments
to
ipfs
as
it's
designed
and
implemented
today,
which
is
really
challenging.
So
I'm
going
to
talk
about
some
of
the
work
that
we've
done.
A
Think
about
what
the
next
steps
are
for:
ipfs
adoption
to
really
grow
and
unbounded
by
the
limits
of
the
very
few
implementations
that
we
have
today.
A
lot
of
the
work
that
we
that
we
do
in
the
in
this
particular
team
and
even
you
know
really
like
the
work
that
I've
done
since
joining
protocol
a
few
years
ago,
is
about
talking
to
people
that
think
about
technology
and
the
work
that
they
and
the
software
they're
building
every
day.
A
Pretty
much
like
this,
where
it's
a
request,
a
response,
and
even
when
they're
working
with
ipfs
oftentimes,
it
still
looks
like
this,
which
is
really
really
challenging
and
often
means
that
that
we're
you
know,
trying
to
figure
out
and
negotiate
how
to
add
something
that
is
paradomatically
different
into
their
environment
and
sometimes
that
there'll
be
husks.
A
Sometimes,
and
you
know,
to
address
a
use
case
or
a
business
need
that
they
have
and
often
and
oftentimes
too,
because
we
think
that
the
that
particular
space
that
working
in
would
be
enhanced
or
improved
or
their
users
would
benefit
by
the
addition
of
ipfs
as
something
that
is
available
and
choosable
to
developers
in
a
given
environment.
A
Because
when
you
add
ipfast,
you
end
up
with
a
topology
that
looks
a
lot
different
with
characteristics
that
are
different
with
use
cases
that
are
different
and
and
architectures
that
are
radically
different
than
what
people
are
used
to
building
today.
There's
a
whole
bunch
of
different
challenges
in
doing
this.
That
technology
has
momentum,
and
it
is
very
difficult
when
adoption
reaches
a
certain
scale
to
change
behaviors,
because
they
became
integrated
that
embodied
the
tools
that
we
use
every
day.
A
Have
a
bunch
of
these
kind
of
assumptions
built
in
to
them
around
what
the
security
model
is,
what
the
privacy
model
is,
where
data
comes
from,
how
it
moves
between
different
systems,
how
fast
or
slow
and
even
out
at
the
glass
and
user
features
are
designed
with
a
bunch
of
the
constraints
of
existing
technologies
in
mind,
and
that's
actually
one
of
the
bigger
challenges
from
you
know.
A
Reorienting
people
around
what
ipfs
can
do
is
the
fact
that
they
assume
a
certain
set
of
behaviors
or
capabilities
that
no,
that
that
are
constrained
to
the
given
network
implementation
or
the
network
architecture.
The
underlying
protocol,
which
are
really
not
true
anymore.
There
also
might
be
new
challenges.
They
have
with
these
new
architectures
new
constraints
that
they're
not
familiar
with
as
well
like
in
most
go
ipfs
apis.
Where
you
make
a
request
that
never
really
truly
ends.
A
It
can
just
keep
trying
for
as
long
as
there's
people
left
on
the
network
to
ask
for
given
resources,
for
example.
So
a
very
big
paradigmatic
difference
from
that,
where
you
make
a
request,
get
a
response.
Call
the
day,
move
on
one
of
the
challenges
that
we
have
in
terms
of
how
getting
things
to
work
is
oftentimes.
These
are
not
technology
challenges
in
ipves
adoption.
These
are
cultural
challenges
in
adoption.
A
Sometimes
these
are
cultural
challenges
in
terms
of
the
technology
norms
and
the
tools
and
platforms,
architectures
and
patterns
that
used
to,
but
also
challenges,
thinking
about
distributed
networks
and
what
they
mean
at
the
political,
philosophical
and
even
sometimes
moral
level,
and
these
are
some
of
the
challenges
that
we
have
with
even
even
really
big
groups,
everything
from
browser
vendors
to
standards,
bodies
in
adopting
ipfs.
A
So
it's
not
oftentimes,
just
a
technical
challenge
of
a
given
implementation
that
that
can
be
problematic
or
is
a
point
of
negotiation,
and
this
is
something
that
really
and
I'll.
You
just
tell
the
story
to
really
underscore
this
in
a
few
different
ways,
but
really
cannot
impress
upon
you
how
serious
this
aspect
of
the
transition
from
from
centralized
technologies
to
decentralized
technologies,
how
important
this
aspect
of
it
is
and
how
much
important
place.
A
So
you
start
by
talking
about
the
web
browser
work
that
we
do
here's
kind
of
like
an
overview
of
what
some
of
the
bigger
web
browsers
today
and
and
their
status
in
terms
of
implementing
our
adopting
some
of
the
technologies
that
we're
talking
about.
I've
got
some
particular,
as
you
can
see,
there's
a
surprising
amount
of
green
here
when
I
actually
wrote
this
up,
which
is
awesome,
but
at
the
same
time
it's
complicated
these.
A
These
oftentimes
are
specific
relationships,
we'll
talk
about
a
couple
of
them
and
and
challenges,
and
sometimes
people
feel
like
they
can
talk
about
it.
Sometimes
they
can't
and-
and
we
have
talked
to
a
lot
of
folks
at
the
major
browser,
vendors
and
there's
ipvs-
is
definitely
increasing
in
recognition.
People
at
least
know
what
it
is.
A
Recently,
the
cto
of
mozilla
wrote
a
post
on
his
private
blog,
not
a
muslim
talking
about
ipfs
and
and
beaker,
and
which
was
really
step
forward
in
terms
of
getting
that
the
attention
on
these
types
of
technologies
and
the
type
of
capabilities
that
they
offer
to
the
web
and
some
of
the
challenges
that
they
post.
A
So
the
things
like
that
are
are,
I
think,
well
we'll
talk
things
like
that
that,
like
that,
as
a
win
in
for
our
team
and
for
the
adoption
of
ipvs
generally,
is
just
having
having
those
conversations,
it's
it's
really
complicated
and
we
we
do
even
at
some
of
the
some
of
the
bigger
ones,
even
in
chrome.
We
have
folks
that,
are
we
sometimes
read
signals
right,
like
google
hasn't
said
anything
about
ipfs
publicly
really
necessarily
are
supporting
it
in
chrome.
A
You
know
we're
working
on
coding,
sorry,
but
we're
getting
really
good
turnaround
times
on
on
code
reviews
for
prs,
for
example.
So
these
are
the
types
of
kind
of
tea
leaf
reading
that
we
do
sometimes
brave
shipped
ipves
support
last
year,
and
this
is
one
of
the
biggest
I
think
victories
of
ipfs
adoption
in
larger
scale.
Applications
brave
has
over
50
million
users
monthly
right
now
and
growing
really
really
fast.
So
this
is
a
really
big
opportunity.
A
This
ipv
is
available
to
over
50
million
people
in
software
that
they
probably
use
daily
or
pretty
close
to
it
that
they
implemented
the
support
for
the
protocol
and
also
bundled
the
ability
to
optionally
turn
on
a
support
for
a
full
node
of
go
ipad
so
that
downloads
go
ip
fast
and
starts
running
it
and
there's
some
things
that
worked
here,
which
is
you
know
again
in
the
it's,
not
all
technical,
all
the
time
we
had
willing,
enthusiastic
collaboration
with
them.
They're
super
interested,
we
embedded
a
engineer
full-time
in
their
team.
A
We
made
a
bunch
of
decisions
around
the
user.
Experience
of
ipfs
now
is
presented
to
end
users
off
by
default,
very
very
clear
privacy
warnings,
and
then
we
experimented
a
lot
like
the
first
first
thing
they
shipped.
What
it
looks
like
today
is
pretty
different.
We
made
a
bunch
of
ux
tweaks.
We
had
to
change
a
bunch
of
things
around
how
the
the
address
bar
is
constructed
designed
and
what
it
communicates
to
end
users.
A
We
shipped
a
kind
of
flight
option
on
by
default,
with
the
full
option
off
by
default
and
the
ability
to
configure
that,
and
then,
like
kind
of
this
cascading
set
of
user
interface
pieces
where
people
could,
if
they
re,
if
they
ran
into
ipf
stuff,
they
would
be
presented
with
these
types
of
options.
So
being
very,
very
careful
is
something
I
think
that
really
worked
here.
A
lot
of
the
problems
are:
how
do
you
visualize?
How
strong
your
connection
is?
A
The
ipfs
go
outgive
us
node
approach
is
really
about
peer,
aggregation
and
bandwidth,
con
and
kind
of,
like
bandwidth
available,
but
pretty
much
just
peer
aggregation,
so
there's
not
really
any
norms
or
design
language
or
ux
work.
That's
really
been
done
around
how
to
communicate
things
like
that.
A
How
to
make
trust
when
trust
is
defined
by
the
fact
that,
with
credit
addressing
and
ipfs,
it
means
that
nobody
has
modified
the
content
that
you
that
you've
asked
for
you,
you,
you
receive
what
you
ask
for,
and
you
were
guaranteed
that
by
the
protocol.
A
However,
the
traditional
web
approach
to
trust
is
that
the
website
you
loaded
was
granted
a
dns
name
and
a
which
is
encoded
into
an
ssl
certificate,
which
you
can
walk
the
ssl
search
chain,
all
the
way
up
to
a
certificate
authority
and
the
combination
of
those
things
and
the
browser
having
that
c8
cert
and
integrated
into
it
means
that
you
can
trust
the
website
so
that
the
way
trustless
defines
radically
different.
It
means
very,
very
different
things
to
end
users
and
in
specific
use
cases.
How
do
these
things
put
together?
A
How
to
communicate
them
still
very,
very
much
undefined,
and
I
think,
one
of
the
biggest
things
that
has
been
a
problem
for
a
long
time
in
idfas,
which
it
was
exacerbated
when
you
actually
gave
regular
people
access
to
a
full
notice
where's,
my
stuff,
with
the
website.
Your
stuff
is
on
that
centralized
website
server
with
ipfs.
Maybe
it's
in
your
node,
maybe
not
it's
pinned
it's
not
pinned
they
got
garbage
collected.
A
Maybe
it's
somebody
else's
node,
it's
out
there
in
the
data
soup
of
the
distributed
web
very
unclear,
and
so
each
one
of
these
things
is
a
learning
for
future
implementations
and
purchase
that
we
take.
We've
been
working
with
gallia
on
chromium
fixes
for
quite
a
while
now
and
really
moved
from.
You
know
like
web
compatibility,
fixes
around
the
security
model
for
local
host
access,
and
things
like
that
into
lean
into
more
directly
addressing
what
it
test.
A
A
Achievement
is
also
not
really
the
end
state
that
we
need
to
be
in
for
a
broader
adoption,
of
what
ifs
implementation
and
native
to
the
web
platform
would
be
so
some
of
the
things
that
have
worked
so
far
in
this
partnership
in
a
community
that
is
generally
skeptical
of
web3
stuff,
generally
crypto,
generally
of
where
that
kind
of,
like
security,
because
of
the
security
and
privacy
assumptions
and
and
models
of
the
web.
A
Today,
of
what
do
the
ibp,
plus
approach
is
treated
very
much
with
skepticism
and
and,
frankly,
is
considered
quite
dangerous
for
a
bunch
of
use
cases,
so
things
that
have
worked
going
very
slowly,
being
very
understanding
and
and
aware
of
the
concerns
that
people
have
a
very
credible
partner
that
has,
you
know
again
has
commit
rights
on
gecko,
webkit
and
chromium
building
up
trust
by
working
on
web
compatibility
stuff
across
all
three
browsers,
not
just
going
let's.
A
You
know
like
bolt
ipfs
onto
here
and
as
fast
as
we
can
focusing
on
the
re-architecture
of
how
chromium
supports
non-hp
protocols
generally
not
going
full
ipfs
again
and
then
really,
you
know
working
to
cultivate
us
relationships
with
the
communities
and
the
people
that
we
need
to
be
able
to
collaborate
with
and
get
code
accepted
and
proposals
accepted
and
be
too.
You
know
who
would
be
embedding
or
bundling
ibfs
in
their
end
user
products
as
well
things
that
have
been
really
challenging
this
really
http
blinders
up
and
down
the
chromium
stack.
A
It
means
it's
going
to
take
a
while
to
do
this
work.
It's
not
just
a
throw
a
bunch
of
throw
a
bunch
of
engineers
on
it
and
see
how
fast
we
can
go.
Really.
The
network
stack
that
we
have
in
go
iphones
today
and
the
live
pdp
approach
of
pure
aggregation
isn't
really
functional
for
most
desktop
class
computers.
It
means
browsers
today
or
at
least
for
desktop
web
browsers,
as
they
are
today
desktop
web
browsers.
Don't
really
have
listening
sockets,
they
don't
have.
They
have
transient
connections.
A
Sometimes
they
have
persistent
connections,
but
a
lot
of
that
is
also
not
not
really
at
the
political
level
it's
not
handled
by
like
in
chromium
and
and
gecko.
It's
an
entirely
separate
network
process.
It
manages
all
that
network
communication,
so
anything
that
is
doing
like
network
activity
outside
of
the
bounds
of
that
architecture
is
really
problematic.
A
So
we
really
need
to
rethink
for
broader
and
native
ipvs
adoption
in
the
web
platform
kind
of
what
the
network
architecture
looks
like
and
I'll
talk
a
little
bit
more
about
that
and
how
this
is
a
recurring
theme
in
the
work
that
we're
doing
ibfs
companion
is
our
browser
extension.
This
is
another
vector
for
us
to
be
able
to
get
into
web
browsers
in
an
interesting
way.
A
It
was
interesting
and
it's
getting
less
interesting,
the
kind
of
surface
area
of
capabilities
and
apis
and
things
that
you
could
do
with
the
web
browser
extension
is
reducing
over
time.
A
It
has
with
manifest
v3,
which
is
a
new
version
of
extension,
apis
and
architecture
of
how
web
extensions
browser
extensions
were
created,
pushed
by
google
and
now
adopted
by
mozilla
who's
expected
to
ship
this.
By
the
end
of
the
year,
the
latest
update
it
really
reduces
what
you
could
do
inside
web
browser.
It
offers
up
some
new,
interesting
opportunities
too,
for
us
to
be
able
to
add
things
like
protocol
support
in
a
way
that
is
less
of
a
less
of
a
battery
and
cpu
destroyer.
A
It's
really
important,
but
also
pushes
on
us
the
need
to
really
radically
re-envision
what
what
kind
of
what
the
architecture
of
ipfs
in
a
web
browser
actually
is
going
to
be
what
it
needs
to
be
so
there's
challenging
there
and
we've
rewritten
ipv's
companion
from
scratch
in
the
in
the
last
couple
of
quarters,
so
we're
ready
for
this
transition,
but
we
did
have
to
remove
features
that
we
had
before
and
whereas
I
think
at
one
point
it
was
really
thought
about.
A
Extensions
might
be
a
vector
for
a
native
like
channel
through
which
we
could
implement
more
native
ipva
support.
That
opportunity
is
just
growing
smaller
over
time
and
we
really
expect
that
even
a
lot
of
our
partners
will
actually
be
pushed
out
into
kind
of
a
companion
type
of
approach
where
we
have
a
local
node
doing
local
http
or
ipc
over
to
that
local
node.
Somehow
mobile
is
an
area
that
we
do.
A
A
lot
of
work
in
you
saw
you
know
mo,
was
doing
some
work
on
mobile
with
agricore,
and
one
of
the
groups
that
was
really
early
in
experimenting
with
mobile
is
birdie
and
bertie
implemented
one.
A
A
very
interesting
approach
of
embedding
go
ipvs
entirely
with
with
swift
and
kotlin
bindings,
so
you
can
more
easily
embed,
go
ipfs
into
mobile
applications,
then,
and-
and
while
this
was
an
incredible
achievement
again
similar
to
brave,
very
early
on
in
the
kind
of
maturation
phase
and
adoption
of
these
technologies,
a
very
much
a
bolting
on
of
something
that
doesn't
kind
of
natively
fit
in
it.
They
also
implemented
a
lib
pdp
transport
for
not
just
bluetooth,
le
but
kind
of
like
a
suite
of
different
platform.
A
Specific
approaches
to
proximity,
communication
and
detection,
including
bluetooth
valley
and
some
other
things
and
they've,
been
experiencing
experimenting
with
kind
of
those
higher
level
patterns
of
proximity
based
connections
that
is
going
to
be
really
really
valuable
in
the
long
term.
I
think-
and
you
know
something
that
worked-
there-
was
having
a
team
that
had
a
very
specific
use
case.
They
don't
they're
not
doing
anything.
A
Broader
ipfs,
related
they're
focused
on
their
messaging
private
messaging,
app
and
they're,
really
using
that
to
drive
development
kind
of
the
same
approach
that
we
saw
in
in
dropbox
talk
earlier.
This,
like
focusing
on
a
very
specific
use
case
and
spiking
on
that,
in
order
to
be
able
to
get
some
really
important,
learnings
and
things
that
can
be
applied
to
the
rest
of
the
system.
A
They
had
a
very
specific
focus
too,
on
local
and
offline
technologies,
and
they
also
have
really
taken
a
kind
of
slow,
slow
development
approach
intentionally
working
directly
with
their
community
working
and
getting
constant
user
feedback,
which
you
know
is,
is
very
different
than
a
lot
of
teams
where
they're
like
all
right.
A
We're
not
going
to
talk
to
users
we're
going
to
sprint
on
this
code,
get
it
to
where
we
think
it
is
what
we
think
it
needs
to
be
and
then
shift
something
they've
really
taken
kind
of
the
opposite
approach
there,
and
only
recently,
I
think,
you've
opened
up
on
public
data.
A
A
lot
of
the
challenges
are
that
they're
kind
of
going
against
the
grain
of
the
architectures
by
putting
go
ipfis
in
there
of
the
native
architectures,
the
network
architectures
of
the
devices
they're
embedding
in
choose
a
lot
of
mobile
device
resources
and
the
kind
of
like
the
process
that
anybody
who's
tried
to
use
go
mobile
integrated
their
application.
That
build
process
is
pretty
tough
and
pretty
tricky
to
get
right.
A
They
spent
a
lot
of
time
working
on
that
because
of
that
not
kind
of
non-native
alignment
and
integration
during
this
another
recent
project
that
we've
been
doing
with
a
company
called
trigram
partnering
on
a
different
approach
towards
native
ipfs
applications
on
android
and
ios,
and
this
is
really
the
opposite
like
how
do
we?
How
do
we
integrate
basic
ipfs
and
user
tasks
into
mobile
operating
systems
in
a
way
that
aligns
very
closely
with
their
user
model?
What
like,
sharing
images,
publishing
images
receiving
images?
A
Things
like
this,
like
basic
things,
documents,
loading
opening,
ipfs
scheme,
urls
or
uris
things
like
that.
So
is
exploration
into
these
types
of
things.
A
We've
got
a
bunch
of
things
working
so
far,
it's
been
really
good
to
start
small,
it's
really
worthwhile
to
align
very
closely
with
the
user
model
of
the
device
that
you're
embedding
ibfs
into
I'm
thinking
about
the
user
tasks
that
are
most
common
to
daily
daily
things
that
that
we
do,
and
that's
really
really
helped
us
in
terms
of
being
able
to
figure
out
what
the,
how
to
prioritize
those
features,
how
what
works
and
what
doesn't
being
able
to
like
relay
the
ipfs
scheme
out
to
any
other
applications
are
handling
that
application
intents
and
things
like
that,
has
all
been
really
good
and
I
think
we're
gonna
actually
end
up,
probably
with
kind
of
a
daily
driver
type
of
application
for
working
with
ipfs
ipfs
data
and
services
through
this
application
over
time.
A
Some
of
the
you
know
that
those
are
the
things
that
worked
well
as
and
and
there
we
were
the
opposite
of
that
from
birdie
we
didn't
go
full
or,
and
everywhere
we
didn't
go
full
ipfs,
just
really
really
limited
bits
based
on
what
the
embedded,
what
the
available
operating
environment
allows
us
to
do.
Where
do
we
go
from
here?
Does
it
end
up
looking
like
a
full
browser
as
one
of
those
challenges
like,
but
where
do
we
take
these
learnings?
How
do
we
apply
them?
A
How
do
we
get
more
people
to
be
able
to
copy
and
use
this
this
code,
this
approach
and
some
of
these
learnings
agricore
you
heard
from
earlier.
I'm
not
gonna,
spend
a
lot
of
time
here,
but
I
do
want
to
underscore
how
important
this
work
is.
This
is
one
of
those
things
where
we
really
learned
a
lot
so
far
around
embedding
and
modifying
and
embedding
chromium
and
also
with
a
little
bit
around
what
the
you
know,
the
the
benefit
of
being
driven
by
a
specific
single
use,
casing
community.
A
So
the
things
that
work
for
that
really
like
laser
focus
on
a
specific
use
case
has
actually
resulted
in
application
model,
learnings
of
the
conversation
with
their
little
microblogging
application
and
the
integration
to
web
platform
itself,
as
opposed
to
trying
to
route
around
the
web
platform
with
things
like
localhost,
urls
and
stuff,
like
that.
That
is
real
honestly,
like
just
in
this
small
grant.
A
In
this
small
period
of
time,
we've
learned
more,
I
think,
about
what
the
what
an
application
model
for
ipfs
would
be
than
a
lot
of
the
previous
work,
where
we
kind
of
like
bolted
on
or
routed
around.
So
it's
been
really
valuable
when
it
comes
to
challenges,
wrote
a
really
long
post,
which
the
first
of
a
couple
really
detailing
kind
of
like
just
how
what
it
takes
to
build
a
chromium
fork
and
and
ship
it
on
a
mobile
device.
That's
really
worth
reading,
so
we're
excited
about
the
outcomes
of
the
work.
A
That's
going
to
happen
there.
Capiloune
is
a
mobile
operating
system.
This
is
based
on
kaios,
which
was
originally
based
on
firefox
os
and
they
forked
the
updated
version
of
kaios,
which
has
much
more
recent
versions
of
gecko
inside
and
we
did
a
grant
with
them
and
to
add
ipfs
features,
and
what's
interesting
here
is
that
they
ended
up
one.
You
have
a
you
know:
a
mobile
operating
system
there's
an
almost
entirely
web
technology
based
that
has
ipfs
and
ibm
smart
and
they're,
also
using
ipfs
and
making
of
it.
A
So
things
like
build
distributions
when
you
actually
download
the
pre-built,
if
you've
ever
done
a
mobile
operating
system
to
download
all
these
binaries
that
need
to
be
put
on
the
device
so
they're
using
ip
test
for
distribution
of
that
which
has
been
really
interesting,
having
full
control
of
the
os
stack,
where
we
have
a
lot
of
like
basically
to
do
whatever
we
want
on
that
operating
system
has
been
really
interesting
for
learning
about
embedding,
and
it's
going
to
be
a
great
place
for
us
to
experiment
with
what
a
with
re-envisioning,
what
a
native
ipos
would
be
on
these
spices.
A
The
some
of
the
challenges
are
really
like.
A
bet
on
gecko
isn't
really
great
at
this
point,
the
you
know,
mozilla
is
not
really
supportive
of
these
kinds
of
efforts
right
now
and
definitely
not
around
web3,
not
supportive
at
all.
They've
definitely
hit
they've
hit
some
issues
too,
and
I
think
this
is
a
blessing
that
occurs
while
using
ipfs
for
the
building
and
distribution
of
the
operating
system.
A
They're
also
hitting
a
lot
of
problems
where
they're
you
know
pinning
to
our
services
like
two
interesting
services
like
estuarian
and
web
3d
storage,
but
then
pulling
them
through
the
gateway
and
getting
problems.
So
they're
kind
of
like
regularly
relaying
issues
that
they're
having
which
is
making
our
services
better
and
the
gateway's
better,
ultimately,
which
is
good,
but
it's
also
challenging
for
them.
We've
definitely
hit
the
the
network
architecture
problem
here.
A
Private
data
is
actually
something
I
didn't
list
here,
there's
a
really
important
use
case
for
mobile
devices,
and
then
I
think
the
last
one
is
again
like
what
is
an
ipfs
application.
We
don't
have
an
application
model,
it's
a
data
layer
and
a
protocol
that
can
be
used
in
infinite
ways
without
having
a
higher
level
security
model.
Privacy
model
features
capabilities,
permissions
model,
it's
a
new
set
of
challenges
to
be
able
to
answer
those
questions.
When
designing
an
application.
We've
been
doing
a
lot
of
open
source,
tooling
integration
too.
A
We
recently
got
ffmpeg
and
mpv
support
landed,
and
this
has
been
fascinating.
Some
of
one
of
the
things
that
worked
here
again
like
not
not
going
full
ip
offense.
It's
like
meeting
the
community
where
they're
at
having
long
like
this
was
months
and
months
of
negotiations
and
conversation
with
that
community
to
figure
out
just
the
right
set
of
environmental
variables
to
be
able
to
configure
what
the
fallback
and
connectivity
schemes
are.
A
We
had
to
learn
the
time
in
the
challenges
section
here
around
how
how
and
what
to
communicate
to
users
about
what
it
means,
when
they're,
using
ipfs
how
to
detect
and
fall
back
to
local
node,
be
able
to
or
fall
back
to
gateways.
While
you
know
trying
for
a
local
node
first
and
hopefully
that
we,
we
actually
start
out
of
this
work,
to
standardize
on
a
little
bit
for
open
source
tools
and
libraries.
A
What
this
ipfs
integration
could
look
like
across
the
broader
base
and
maybe
eventually
operating
system
integration,
we're
working
on
curl
as
well,
and
there
are
patches
there
and,
interestingly,
like
really
quick
when
you're
trying
to
get
other
people
to
adopt
your
stuff
or
add
your
stuff
to
their
stuff,
instead
of
them
getting
to
use
your
software,
which
is
really
different
dynamic.
You
know
the
the
pro
maintainer
badger
immediately
was
like.
I
can't
find
this.
A
You
could
point
it
to
our
ipv
specs
repo,
but
if
you
ask
anybody
that
works
on
the
advanced
project,
they're
like
no,
no,
no,
no,
don't
look
at
the
iphone
specs
repo
that
goes
code
is
the
reference
for
the
spec.
So
we
have
a
really
complicated
situation
for
even
people
that
are
supportive
and
interested
in
adopting
ipfs
when
pointing
to
our
own
specification
for
the
protocol,
which
is
really
a
really
big
challenge.
Ibps
tiny
is
another
interesting
and
different
implementation
approach.
A
A
This
idea
is
to
run
this
on
better
devices
and
also
some
of
the
work
that
we're
doing
in
with
space
industry
and
what's
worked,
we're
not
totally
sure
yet,
because
we
haven't
deployed
this
code
anywhere,
not
not
trying
to
do
lib
pdp
at
all
so
far
has
worked
and
that
they've
gone
farther
in
the
construction
of
the
core
libraries
and
things
like
that
and
honestly,
these
devices
that
we're
looking
at
are
going
to
be
able
to
run
full
look
vp
anyway.
A
One
of
the
biggest
challenges
in
this
kind
of
work
is
the
first
question
everybody's
like.
Why
is
c,
plus
plus
and
every
time
I
hear
that
question,
I
have
to
be
patient
and
unders
and
really
explain
kind
of
the
dynamics
that
we
have
and
in
getting
people
in
and
meeting
people
where
they're
at
in
order
to
be
able
to
increase
the
chances
of
adoption.
The
embedding
world
is
almost
entirely
c,
plus
plus
people.
Why?
A
Why
not
rest
and
rust
and
embedding
is
while
it's
way
more
mature
than
it
was
three
four
or
five
years
ago?
It's
not
the
default,
it's
very
far
from
it
and
the
number
of
production
devices
when
you're
thinking
about
like
hundreds
of
millions
of
devices
being
manufactured
and
shipped
software
change
in
in
that
type
of
industrial
scale,
is
very,
very
slow.
A
So
we
need
to
be
very,
very
careful
and
people
who
are
going
to
be
making
adoption
choices
around
protocols
are
going
to
be
using
c
plus
for
for
what
another
decade,
two
three
four,
so
we're
also
doing
some
work
in
encouraging
bed
and
rust
useful.
We
can
things
like
this
like
these
are
embedding
experts
who
work
in
space
industry
and
connected
device
industry,
and
for
for
them
it
was
like
we
have.
The
conversation
for
them
is
very
clear
choice
that
the
simplest
plus
was
going
to
be
the
best.
A
So
sometimes
the
the
biggest
challenge
is
our
own
communities
who
think
they
know
better
about
a
whole
given
industry
or
environment
or
area,
and
and
aren't
really
interested
in
this
particular.
You
know
the
approach
towards
implementation.
A
Finally,
one
of
the
areas
that
we're
pushing
on
right
now
too
is
space
industry
where
there's
a
bunch
of
different
use
cases
where
kind
of
like
offline
local,
first
by
default
data,
architectures,
configura,
configurationlessness
and
nodelessness
of
ipfs,
when
you're
able
to
refer
data
by
content
addresses
instead
of
locations,
also
very
very
powerful
features
when
it
comes
to
very
slow
dodgy
communications
and
very
expensive
data
communications
platforms,
or
you
might
have
space
to
space
devices
that
need
to
kind
of
like
have
loosely
coupled
data
connections
and
interactions,
ipfs
again
very,
very
powerful
way
to
address
some
of
these
use
cases.
A
Things
like
aggregating
data
across
when
you
have
like
you
know,
four
six
minute
windows
of
data
availability
today
as
satellites
are
going
by
things
like
ipvs
and
be
able
to
refer
to
larger
data
sets
in
aggregate
across
a
number
of
different
crown
stations.
It's
gonna
be
really
interesting.
We're
gonna
do
some
tests,
hopefully
in
the
next
year,
with
different
groups,
are
interested
in
this
and
and
again
like.
I
don't
think
we
know
what's
worked
well
yet
other
than
assuming
we.
A
We
know
so
far
that
the
network
architecture
of
our
current
implementations
is
a
non-starter
really
given
the
constrained
network
environments
that
we
need
to
operate
in.
Some
of
the
other
things
are,
unsurprisingly,
aside
from
highly
constrained
environments,
are,
you
know,
really
highly
proprietary
code
and
companies
that
are
and
people
that
are
used
to
working
under
that
type
of
secrecy
and
operations,
so
we'll
be
able
to
share
more?
A
But
I
think
it's
really
gonna
push
on
our
assumptions
around
what
the
network
architecture
of
ipfs
needs
to
be,
so
that
that's
pretty
much
the
the
tour
through
some
of
the
challenges
of
things
that
have
worked,
things
that
haven't
worked
where
the
cur
we've
taken
the
current
implementations
and
jammed
them
into
environments
where
that
they're,
maybe
hostile
to
it,
for
a
variety
of
different
reasons.
A
I
believe
ivfs
does
not
have
an
application
model
and
that
technically
neither
does
http,
but
the
unbelievable
success
in
the
web
platform
of
being
in
everybody's
daily
life
almost
all
day
every
day
has
made
that
application
model
and
really
made
clear
that
having
an
application
model,
that
kind
of
like
very
clear
idiomatic
that
is
agreed
upon
by
none
of
the
parties,
standardized
interoperable,
really
increases
the
chances
that
people
can
build
the
things
they
need
to
build
and
that
they
can
do
it
in
ways
that
are
safe
for
their
users
and
so
develop
the
development
of
that
application
model
and
the
integration
with
the
web
platform
at
some
level.
A
I
think
it's
an
incredibly
important
area
of
work
for
obvious
adoption
and
a
gap
that
we
have
not
yet
filled,
but
we're
making
some
progress
there.
I
think
this
implementation
today,
I
think,
is
inverted
like
we
really
by
by
developing
a
node
first
application,
where
we
say
you
run
a
node
that
has
really
been
the
num,
probably
the
biggest
point
of
friction,
and
even
getting
people
that
really
are
excited
about
it
to
actually
be
able
to
adopt
ipfs
we
need.
A
We
need
people
to
be
able
to
add
ipfs
to
their
stuff,
instead
of
forcing
them
to
run
ipfs
and
then
figure
out
a
way
for
ipfs
to
interact
with
it.
The
local
http
api
approach
is
really
cumbersome,
even
even
though
it
seems
like
it
wouldn't
be.
It
causes
a
lot
of
issues.
A
Local
local
hp,
conduction
isn't
well
supported
the
web
platform
anyway,
and
that's
one
of
the
things
that
we
really
push
on
the
edge
of
on
our
work
with
galia,
and
we
have
it
it's
better
than
it
was,
but
even
still
like
webkit
won't,
won't
make
some
of
the
fixes
that
we
need
for
it
to
really
work.
There's
not
enough
libraries
from
the
communities,
developing
libraries
for
languages
themselves,
and
I
really
wanted
to
make
clear
that
distinction
like
it's.
Not
that,
like
we
like,
we
can
go.
A
A
There's
like
not
really
a
reasonable
choice
for
something
that
is
native
and
idiomatic
to
python,
for
example,
the
number
two
programming
language
in
the
entire
world,
so
that
that
is
really
a
huge
gap
and
we're
really
in
investment,
strong
ownership
and
partnership
and
collaboration
with
the
communities
who
are
building
their
their
stuff
and
their
way
as
opposed
to
trying
to
get
them
to
come
to
us.
A
I
think
language
elitism
is
also
really
really
challenging
like
thinking
well,
why
would
you
and
why
would
you
implement
ibfs
and
javascript
when
you
could
do
it
and
go?
It
would
be
much
better
for
that.
I
I
really
believe
that
when
it
comes
to
technology
adoption,
there's
no
best
tool
for
the
job.
There
are
choosable
tools
and
developers
choose
the
tools
that
are
available
to
them
and
there's
a
bunch
of
availability
can
be
defined
in
many
different
ways.
What
is
the
language?
A
I
know
what
what
is
the
operating
environment
that
I
have
to
run
in,
not
the
one
you
would
love
for
me
to
run
it
there's
like
all
kinds
of
reasons
why
people
make
choices
around
of
make
technology
choices
and
adoption
choices,
and
you
need
to
understand
the
reasoning
behind
them
and
oftentimes.
That
is
not
the
the
you
know,
lead
engineer
of
project
x
deciding
what
the
what
the
best
tool
for
the
job
is.
This
is
especially
true
for
something
that
calls
itself
a
protocol,
but
we
have
to
be.
A
We
have
to
be
choosable
in
in
all
of
the
environments
and
that's
how
http
one
we
need
to
be
like
water.
In
that
same
way,
transport
transport
agnostic
cannot
mean
only
limp
p2p,
and
I
think
this
is
one
of
the
things
that
is
like
when
we
talk
about
ipfs
oftentimes,
we're
talking
about
with
p2p,
especially
when
we're
talking
about
challenges.
What
I'm
talking
about.
You
know
code
that
people
and
apis
people
don't
really
understand
how
they
work.
The
high
dependency
on
public
dht,
and
things
like
that
too.
A
Without
strongly
decoupling,
these
things,
when
we
talk
about
them
and
really
treating
ibfs
as
something
independent
of
the
pdp,
where
the
pdp
can
be
used
for
the
for
the
transport
layer
for
the
for
the
network
architecture
layer
underneath
we
need
to
be
able
to
have
other
alternatives
for
at
the
network
layer
and
then.
Finally,
the
the
idea
of
transient
network
connections
versus
persistent
aggregation
as
a
model
for
connectivity
and
improving
the
chances
that
a
given
request
will
actually
succeed
for
data.
A
So
we
need
to
be
able
to
have
models
where
you
can
have
an
ipfs
connection,
maybe
between
one
two
between
two
three
four
peers
to
be
able
to
exchange
data
and
then
shut
that
network
down
or
some
alternative
ways
of
looking
at
how
how
transmission
of
data
and
connection
between
peers
happens
that
isn't
put
on
the
on
the
public
data
see
or
put
encrypted
data
onto
public
networks
may
be
able
to
have
a
much
more
adaptable,
configurable
approach
towards
how
what
a
network
is
and
how
it
is
constructed
how
data
is
routed
around
it.