►
From YouTube: Take what you need; protocols as libraries - Carson Farmer // IPFS Implementations Workshop
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
Yes,
so
I'm
out
in
the
middle
of
the
bc
forests
and
last
night,
I
was
literally
sitting
around
a
campfire
with
my
laptop
putting
this
presentation
together
kind
of
reflecting
a
little
bit
on
on
textile
in
my
own
journey
as
part
of
the
interplanetary
ecosystem,
which
is
a
term
I
just
invented,
but
we'll
refer
to
throughout.
A
This
talk,
I
think,
and
and
eventually
got
pretty
dark,
but
this
the
glow
of
the
screen
and
the
the
slowly
burning
embers
helped
me
to
reflect
a
little
bit
on
how
we
got
here
and
some
of
the
things
that
enabled
textile
and
tableland
to
build
the
the
tools
and
protocols
that
we
did.
So
this
is
actually
a
talk.
I've
wanted
to
give
for
a
long
time
and
then,
of
course,
I
do
the
thing
that
I
always
do,
which
is
leave
it
to
the
last
minute
and
write
it
while
I'm
sitting
around
the
campfire.
A
But
anyway,
let's
see
if
this
is
how
this
goes
and
I'll
take
it
from
there.
So
me
and
my
team
textile-
some
of
you
may
remember
us
from
such
products
as
threaddb
or
buckets
or
maybe
more
recently,
tableland
or
the
textile
hub,
or
maybe,
if
you
were
you've,
been
around
the
ip
ecosystem.
A
As
long
as
we
have,
you
might
remember
a
product
we
built
called
textile
photos,
which
was
one
of
our
first
like
intros
into
this
space,
and
it
was
an
attempt
to
build
an
ipfs,
enabled
peer
into
a
mobile
browser,
and
we
did
that
and
we
learned
a
lot,
and
so
I
wouldn't
say
that
textile
is
sort
of
like
oh
geez
and
the
strictest
things,
because
ipfs
had
been
around
for
quite
a
long
time.
But
we
definitely
were
here
before.
A
Storing
data
for
nfts
on
ipfs
is
cool,
so
I
consider
that
a
pretty
good
sort
of
like
og
status
there,
but
anyway,
we've
been
around
for
a
while,
probably
at
least
six
years,
and
so
in
this
talk,
I'm
going
to
refer
sort
of
broadly
to
things
like
ipfs
and
ipld
and
lib
p2p
and
multiformats,
and
all
those
concepts
that
go
together
to
form
the
broader
ipfs
protocol
and
ideas
as
the
interplanetary
ecosystem.
A
So
if,
if
I
say
that
ip
ecosystem,
that's
what
I'm
talking
about
anyway,
so
we've
been
around,
and
so
we
I've
kind
of
developed,
multiple
perspectives
on
on
the
ip
ecosystem
in
general,
and
I
spent
a
lot
of
time
in
the
sort
of
early
days
of
of
textile,
just
really
writing
about
the
ip
ecosystem,
blog
posts,
how
how-to
guides
giving
talks
running
workshops
and
discussions
and
a
big
piece
of
that
was
driven
by
us.
Coming
in
and
saying
like.
A
Oh
my
gosh,
this
like
content
addressable
like
user-owned
storage
framework,
this
peer-to-peer
thing
solves
a
real
concern
in
our
problem
that
that
our
team
had
which
was
sort
of
user
sovereignty
of
data
on
the
internet
and
and
so
we
just
sort
of
dove
in
and
said
well,
can
we
build
consumer
apps
on
top
of
this
right
now
and
how
easy
is
that
going
to
be?
A
A
So
we
came
in
initially
as
sort
of
like
an
application
user
having
fun
playing
with
ipfs
and
a
developer,
trying
to
build
a
consumer
application
on
top,
and
we
actually
got
some
made
some
pretty
decent
progress
on
that.
We
actually
built
a
mobile
app.
That
was
spinning
up
and
spinning
down
a
ipfs
peer
on
on
ios
and
android,
and
we
showed
up
to
the
first
ipfs
camp
with
a
somewhat
working
prototype
and
yeah.
You
could
also
use
it
as
a
hand
warmer,
and
that
was
pretty.
That
was
pretty.
A
You
know,
sort
of
useful
side
effect,
but
it
worked,
and
this
is
pretty
exciting
and
it
took
us.
You
know
quite
a
lot
of
development
time
and
I
want
to
say
we
could
not
have
gotten
to
where
we
did,
even
without
a
lot
of
the
earlier
work
that
like
open,
open
bazaar
and
some
of
these
other
teams
had
done
where
we
literally
borrowed
open
source
code,
and
you
know,
figured
out
how
to
export
or
figure
out
how
to
sort
of
leverage
that
and
get
it
going
on
mobile.
A
So,
like
you
know,
this
is
the
classic
open
source
shoulders
of
giants.
Sort
of
thing,
but
we
we
demoed
it
there
and
that
was
pretty
exciting
and
it
took
us
quite
a
while
to
get
to
that
point,
and
so
at
some
point
we
started
to
move
a
little
bit
further
down
layers
of
the
sort
of
like
application
stack
to
becoming
more
like
protocol
users,
and
we
really
got
our
hands
dirty
and
started
tinkering
with.
You
know
aspects
of
the
ipfs
protocol
and
developing.
A
A
Let's
take
a
step
down
and
become
protocol
designers,
ourselves
and
protocol
developers
ourselves
and
actually
start
to
build
the
tools
that
we
wish
that
we
had
in
the
first
place,
and
I've
got
a
little
story
coming
up
that
you
know
digs
into
that
a
little
bit
but
anyway
long
story,
short.
We've
approached
this
and
me
personally
have
approached
ipfs
in
the
ip
ecosystem
from
multiple
perspectives.
A
We've
been
involved
in
that
and
we've
moved
literally
from
the
outside
in
or
from
the
top
to
the
bottom
of
this
of
this
ecosystem
and
along
the
way
I
have
you
know,
I've
formed
a
lot
of
opinions
and
I'm
going
to
share
my
opinions
with
you
today,
because
you're
a
captive
audience
and
I
was
invited
so
there
you
go
so
I've
formulated
a
bunch
of
opinions
along
the
way
and
a
lot
of
it
is
about.
A
You
know
how
protocols
and
ideas
get
used
in
general
so,
like
I
said,
I'm
going
to
share
those
with
you
and
then
at
the
end,
I'm
going
to
try
and
you
know,
allude
to
a
little
bit
of
what
I
think
we
need
to
focus
on
next.
So
with
all
of
that
in
mind,.
A
So
you
know
you
can
just
basically
stop
listening
if
you
really
want
for
the
next
20
minutes.
If
you
take
away
nothing
else,
it's
that
I
strongly
think
we
we
as
an
ecosystem,
should
and
kind
of
do
favor
composability
over
just
about
anything
and
when
you're
working
and
talking
about
composing
protocols.
This
is
a
pretty
the
fundamental
piece
of
a
piece
of
or
a
way
to
approach
things,
and
so
I
think
the
interplanetary
ecosystem
has
got
a
lot
of
things
right
and
a
few
things
wrong.
A
A
A
It
does
smell
like
smoke
in
here,
actually
right
now,
just
from
from
the
comets
here
it
does
smell
like
smoke,
and
so
we
were
sort
of
reevaluating
how
we
were
going
to
approach
this
stuff,
and
we
decided-
and
I
kind
of
alluded
to
that
earlier-
that
it
took
us
a
while
to
get
to
the
textile
photos
product
point,
and
so
wouldn't
it
have
been
nice
if
we
could
have
just
spent
less
time
doing
that
and
bootstrapped
a
project
like
that
more
quickly.
A
So
we
decided
that
some
core
building
blocks
were
missing
and
that
what
we
needed
was.
We
were
going
to
see
if,
if
we
really
wanted
to
I'm
sorry
there's
a
child
climbing
on
the
roof
of
the
jeep
here
right
now,
it's
a
little
distracting.
A
So
anyway,
we
decided
there
was
some
missing
building
blocks
and
that
we
were
just
gonna
go
build
them
so
that
basically,
the
next
team
that
came
along
and
decided
to
build
a
textile
photos
product
would
get
there
faster
and
they
would
basically
reduce
what
we're
at
the
time,
calling
time
to
failure.
The
idea,
here
being,
I
want
to
test
out
an
idea
and
see
if
it
fails
very
quickly
so
that
I
can
move
on
to
the
next
big
idea
and
we
need
that
happening
a
lot.
A
We
need
that
flywheel
of
application
developments
to
go
to
to
sort
of
go
faster
and
faster
and
faster,
so
they'll
be
more
developers
coming
in
and
building
good
products,
and
so
that's
what
we
needed
to
do
to
sort
of
like
induce
that
mass
adoption
to
deweb
more
developers,
building
more
things,
failing
more
quickly,
finding
things
that
work
and
moving
on,
and
so
we
decided
okay.
Well,
what
do
we
really
need
to
make
a
mobile
application
for
photos
and
other
things
we
wanted
to
build?
A
Well,
we
needed
a
database,
we
needed
mutability,
we
needed
identity,
but
that
seemed
really
hard.
So,
let's
not
build
that.
We
needed
mutable
storage
and
we
needed
a
whole
lot
of
other
things,
and
then
we
needed
it
to
be
easy
to
use
and
we
needed
to
get
it
into
the
hands
of
developers
that
we
were
targeting.
A
A
We
put
it
out
there
for
people
to
use,
and
lo
and
behold,
people
started
using
it
and
of
course,
we
already
had
a
large
body
of
code
built
up
from
pieces
about,
go
ipfs
and
go
open,
bazaar
and
other
places,
but
we
decided
to
start
from
scratch
for
this
project
and
here's
why
we
didn't
need
the
whole
kitchen
sink
for
this
right.
We
didn't
need
ipns,
we
didn't
need
the
concept
of
pinning,
we
didn't
need
a
gateway
or
if
we
did,
it
was
going
to
be
a
hyper,
optimized
and
hyper
simplified
gateway.
A
We
didn't
actually
even
need
pub
sub.
We
didn't
need
mutable
file
systems.
We
didn't
need
a
lot
of
these
other
things.
We
did
need
bit
swap
or
something
like
it.
We
did
need
dag-based
data
structures
and
in
fact
we
did
with
encrypted
dags
for
thread
db.
It
led
to
a
bunch
of
collaborations
with
other
ecosystem
members
like
ceramic
and
fission
and
other
folks,
and
and
we
actually
worked
on
a
spec
with
ceramic
for
dag
jose.
A
It
led
to
a
bunch
of
discussions
with
the
ipld
team
and
other
developers,
and
it
even
helped
to
push
the
multi-base
encoded
public
string
format
for
the
did
spec.
The
official
did
spec.
So
in
moving
down
this
stack
and
making
some
of
these
decisions
and
getting
our
hands
really
dirty.
A
We
got
into
different
layers
of
the
protocol
development,
so
we
did
need.
We
did
need
things
like
this
and
we
we
were
able
to
leverage
those
things
and
so
we're,
like
you
know.
How
are
we
going
to
do
this?
Go
ipfs
at
the
time
was
a
sort
of
very
large
single
monolithic
piece
of
software.
That
was
a
little
bit
hard
to
take
apart.
A
I
I
wrote
a
note
here
for
months,
but
I
think
it
was
weeks
to
develop
the
threads
protocol,
and
so
not
only
were
we
interested
in
sort
of
like
bootstrapping,
this
flywheel
of
software
development,
but
the
composability
of
the
protocol
layers
that
we
were
working
on
made
it
possible
for
us
to
facilitate
that
bootstrapping
and
here's
the
other
cool
thing.
We
were
also
able
to
quickly
move
to
implement
ipfs
lite
in
typescript
to
help
drive
our
typescript
implementation
of
threads.
A
You
know
moving
forward
until
we
actually
started
to
you
know,
get
typescript
types
natively
in
a
lot
of
libraries
and
now,
basically,
everything
is
typed,
and
so
we
were
able
to
not
only
very
quickly
because
we
could
only
pick.
We
only
needed
the
little
pieces
that
we
needed
to
get
going,
pull
together
an
entirely
new
implementation
in
a
very
short
amount
of
time,
but
that
implementation
iteratively
led
back
into
updates
for
the
rest
of
the
ecosystem.
A
The
big
thing
there
was
that,
as
I
mentioned,
only
needed
to
take
what
we
needed
and
we
didn't
have
to
take
anything
that
we
didn't
even
didn't
need.
But
this
wasn't
just
software
libraries
right.
This
was
actually
the
actual
protocols
and
pieces
of
the
ip
interplanetary
ecosystem,
like
multi-formats
multi-formats.
Were
there
ready
to
compose
with
other
things,
so
threads
supports
is
its
own
multi-format
and
uses
a
bunch
of
components
of
multi-formats
and
multi-codecs,
and
all
that
good
stuff.
A
A
A
So
here
are
my
opinions
they're
all
here,
and
these
are
opinions
that
I
formulated
yeah
pro
tip
there.
That's
right,
yeah
inhale
a
little
bit
of
smoke
right
before
you
talk.
A
So
these
are
these
are
my
opinions
you
can
you
can
check
them
out
there
and
enjoy
them,
but
I'll
elaborate
on
them
a
little
bit.
So
these
are
my
opinions
that,
when
designing
extending
and
implementing
interpretatory
protocols,
we
need
to
do
these
things.
So
I
already
mentioned
favorite
composability
over
just
about
everything.
You
know
everybody
loves,
lego
and
the
pieces
are
really
fun
to
play
with,
but
it
also
means
that
I
can
play
with
them
and
stick
them
together
in
all
different
places,
and
this
lego
analogy
gets
overused.
A
A
So
you
know
that
sort
of
means
like
saying
battle
tested
default
and
I
think
my
opinion
there
is
the
foot
guns
are
fine.
We
can
hand
people
foot
guns
as
long
as
they're
locked
up
in
a
case
right.
So
if
it's
we
can
make
them,
we
can
let
them
do
some
pretty
wild
things,
but
they
got
to
know
what
they're
doing,
and
I
think
that's
a
nice
nice
way
to
think
about
it.
A
So
foot
guns
are
okay,
if
you
lock
them
in
a
case
things
into
smaller
things
is
really
useful,
but
no
smaller
than
necessary.
A
If
you
had
to
build
everything
with
those
little
water,
legos
we'd
be
pretty
sad
about
that
right
and-
and
I
think
lid
p2p
and
a
bunch
of
projects
are
particularly
good
at
finding
that
balance.
A
A
The
other
thing
is
we
don't
want
everything
under
one
roof.
This
is
a
lesson
I
learned
along
the
way
when
we
were
interfacing
with
with
different
projects,
and
I
was
actually
reminded
of
the
importance
of
this
recently
when
I
was
talking
about
our
bit
swap
implementation
in
rust
on
discord-
and
I
said
oh
it'd
be
nice.
If
there
was
one
version
to
collaborate
on,
but
a
dean
reminded
me,
I
think
that's
not
right
it's.
A
Actually,
it
would
be
nice
if
there's
one
place
to
go
to
discover
where
all
of
the
implementations
are,
but
many
implementations
are
useful,
which
reminds
me
we
need
more
implementations
of
everything
and
there's
the
obvious
reasons
for
that
which
are
like
resilience
and
finding
bugs,
and
you
know
different
languages
mean
that
you
have
different
people
contributing
and
all
the
other
reasons
that
we
think
like
multiple
http
implementations
are
important
or
multiple
eth
clients
are
important,
blah
blah
blah.
These
are
all
good
reasons
right.
A
Another
one
is,
I
don't
really
like
go
as
a
cult
of
language,
so
maybe
that's
a
reason,
but
there
are
less
obvious
ones
as
well
right
for
there
to
be
multiple
language
implement
implementations,
we
need
very
clear
specs,
which
are
improved
as
new
implementations
take
off.
I
think
also
there's
a
there's
something
around
language
driven
thinking
right.
If
I
am
working
in
a
programming
language
that
allows
one
thing
I
might
try
and
leverage
or
use
that
sort
of
thinking
in
my
spec
development.
A
I
think
there's
a
lot
like
spoken
language
right.
It
influences
the
way
you
think,
or
at
least
some
people
think
that
that's
the
case,
but
probably
the
language
they
speak,
had
an
influence
on
that.
A
So,
like
spoken
language,
software
software
language
might
influence
how
you
think
about
an
approach,
and
so
a
new
language
might
help
us
to
think
differently
about
how
to
design
a
spec.
So,
for
instance,
I
have
no
idea
if
this
is
the
case,
but
rust
has
generics
which
maybe
influences
how
we
would
implement.
A
You
know
the
p2p
or
some
component
in
that
which
in
turn
helps
to
better
define
the
spec,
which
in
turn,
helps
to
better
find
differences
in
potential
bugs
with
the
go
version
which
in
turn
makes
it
more
resilient
overall
on
the
network,
which
leads
to
an
overall,
better
user
experience
which
in
turn
brings
in
more
users
which
in
turn,
helps
to
drive
ipfs
adoption
and
so
on
and
so
forth
profit.
So
all
of
these
things
are
pretty
good
things,
so
software
diversity
is
a
thing.
A
It's
just
like
it's
silly.
We
don't
even
need
to
be
thinking
about
competition
or
anything
like
that
when
there's
when
there's
folks,
all
working
together,
because
we're
just
so
early
still
that
you
know
competition
is
sort
of
like
arguably
an
illusion
and
you're
about
to
see
a
figure
that
doesn't
make
any
sense.
A
That's
because
last
night
I
was
working
around
the
campfire
and
I
didn't
have
internet
access,
and
so
I
left
myself
a
little
to
do
here,
but
this
is
a
little
aside
that
I
wanted
to
talk
about,
which
is
you
know
all
of
you
just
picture
in
your
head.
Now,
the
classic
xkcd
comic
of
that
complex,
open
source
stack
and
there's
the
tiny
little
piece
there,
and
ideally,
this
ecosystem.
A
A
Okay,
so
I'm
gonna
start
to
yes,
thank
you,
brandon
for
the
xkcd
comment
yeah.
So
there
you
go,
those
are
carson's.
A
Opinions
come
up
around
the
campfire
in
the
middle
of
british
columbia,
forest,
take
them
or
leave
them,
let's
see
where
we
go,
but
what's
next,
if
you,
if
you
think
about
that
more
implementations,
I
just
I
have
a
huge.
I
know
the
sort
of
like
bitcoin
world
doesn't
think
these
things.
There
should
be
one
implementation
to
rule
them
all
strongly
opposed.
To
that
viewpoint,
the
more
implementations
we
have
the
better
and
for
so
many
reasons
that
diversity
is
a
good
thing.
A
A
I
think
that
one
of
the
big
lessons
that
the
textile
team
learned
when
developing
applications
on
top
of
peer-to-peer
protocols
is
like
clients
are
a
bombing
great
idea,
so
we
want
to
enable
more
and
more
light
clients
and,
as
a
result,
enable
more
and
more
heavy
services.
So
these
are
these
things
where
a
light
client
can
defer
a
lot
of
its
peer-to-peer
interactions
and
things
like
that
to
some
super
node
somewhere
else
on
the
network
doing
a
lot.
This
really
does
enable
local
first
style
applications.
A
So
let's
have
a
lot
of
light
clients
and
heavy
services
and
everything
in
between
and
then
yes
ipfs,
camp
2.0.
Please
I
see
it's
already
happening.
I
expect
my
invitation
in
the
mail
shortly.
A
Let's
do
that
because
the
more
we
get
in
front
of
each
other,
the
more
we're
going
to
discover
all
of
the
commonalities
that
we're
working
towards
to
solving
and
for
those
of
you
who
around
for
ipfs
camp
1.0
the
months
following
that
were
some
of
the
most
crazy
in
terms
of
the
sort
of
cambrian
explosion
and
software
that
I've
seen
in
a
while.
So
these
types
of
events
really
do
make
a
difference.