►
Description
IPFS Implementations - presented by @jbenet at IPFS þing 2022 - IPFS Implementations - https://2022.ipfs-thing.io
A
A
A
Each
talk
may
cover
what
the
implementation
is
for
the
problems.
It
solves
the
solutions
it
offers
how
it
works.
What
the
architecture
is
some
interesting
challenges
along
the
way
in
building
it
who
the
team
is
building
it,
the
traction
so
far,
the
usage,
the
road
map
towards
the
future
and
maybe
pain,
points
that
the
implementation
ran
into
or
that
is
trying
to
solve
or
that
it
looks
to
solve
in
the
future.
A
So
here's
a
preview
of
the
track,
we're
gonna,
go
speak
about
implementations
at
a
high
level.
We're
going
to
hear
from
dietrich
about
lessons
for
putting
fpfs
in
weird
places
we're
going
to
hear
from
a
dean
about
kubo
the
og
implementation,
we're
going
to
hear
from
lydol
about
ipfs
gateways
and
also
from
lightro
lytle
about
ips
companion,
ips,
desktop
and
brave,
we're
going
to
hear
from
xpeed
and
matteos
matthews
matias
about
when
fs.
I
like
pronouncing
it
right,
yeah,
it's
a
great
name
by
the
way.
Winfs
is
awesome.
A
I
had
to
like
search
my
dag
store.
Then
we're
gonna
hear
from
hector
about
ipfs
cluster.
Then
I'm
gonna
talk
a
bit
about
filecoin
as
an
ipfs
implementation
or
an
ipv5
system
we're
going
to
hear
from
ayush
about
lotus
and
which
I
think
is
the
ips
implementation
that
handles
the
largest
volumes
of
data.
A
Then
we'll
hear
from
michael
about
web
scale.
Ipfs
then
from
j
loglin.
I
think,
is
that
pronouncing
it
right
great
about
estuary.
Another
large
implementation
for
large
data,
we'll
hear
from
corey
about
ipfs
operator,
a
kubernetes
tooling
then
from
daniel
about
auspinner.
Is
that
correct,
a
spinner?
A
Yes,
maybe
daniel
here?
Yes,
then
we'll
hear
from
gus
about
lib
ipfs,
an
upcoming
library,
with
components
for
building
ips
implementations,
then
from
achingbrain
about
js
ipfs
and
perhaps
we'll
hear
about
a
new
name.
Maybe
yes,
maybe
not,
maybe
you'll
get
to
vote
on
a
new
name.
I
don't
know
no
promises
we'll
hear
from
alari
about
aqua,
a
language
for
building
decentralized
protocols
and
how
we
might
be
able
to
use
it
to
build
ipfs
itself
and
then
we'll
hear
from
ianopoulos
about
pure
gross
the
private
file
system.
A
Great,
so
lots
of
amazing
things.
This
track
is
going
to
move
fast
again,
15
minutes.
Only
if
you
have
questions,
I
recommend
you
drop
them
on
slack
and
then
ask
them
at
the
end.
If
there's
time,
if
you
want
to
go
talk
about
it
right
after
then
like
just
leave
the
room,
as
the
speakers
are
changing
or
at
the
next
break,
if
it
seems
too
disruptive
and
use
the
unconference
track
to
to
host
discussions
either
way.
A
So
this
is
not
a
a
a
a
full
history,
but
the
first
set
of
implementation
implementations
came
around
2014
15..
I
started
with
go
ipfs
and
js
ipfs.
We
had
a
web
ui
very
early
on.
We
had
a
daemon
and
a
gateway,
and
we
had
like
the
kind
of
end-to-end
model
for
how
an
http
client
would
would
be
able
to
use
an
ipfs
node.
Then,
after
that
we
had
started
getting
bind
api
bindings
and
implementations
in
other
languages.
A
A
few
other
implementations
started
to
appear
things
like
pi,
ipfs,
cbs,
plus
ipfs
and
so
on,
but
I
think
none
of
them
quite
made
it.
Then
we
got
things
like
ipfs
companion,
which
managed
to
bridge
the
experience
with
browsers.
Then
we
got
desktop
to
make
the
web
ui
packaging
much
nicer.
Then
we
got
cluster
a
way
to
kind
of
coordinate
large
numbers
of
ipfs
nodes.
Then
we
got
tools
like
ipad,
which
were
like
kind
of
very
lightweight
implementations.
A
There
are
a
lot
of
other
tools
like
that,
so
this
is
just
one.
Then
we
got
a
whole
slew
of
new
gateways,
so
many
other
groups
and
organizations
started
hosting
their
own
versions
of
gateways
using
the
traditional
gateway
code,
sometimes
patching
it
sometimes
adding
new
features,
and
so
on
many
early
pinning
services
and
groups
like
cloudflare
and
so
on,
deploy
their
own
gateways.
A
A
Then
there
were
a
whole
set
of
applications
and
application
systems
that
started
blending
in
with
ipfs
ways
of
dealing
modeling
the
data
and
moving
around
the
data,
and
so
on
things
like
the
the
the
tooling
that
kind
of
went
into
the
the
browser
so,
for
example,
special
libraries
that
got
shipped
with
opera
or
brave
in
braves
exam
case.
We
have
go
ipfs,
then
we
got
things
like
piergos
and
textile
and
query
and
many
other
applications
in
the
first
first
waves.
Then
we
got
a
lot
of
pending
services.
A
Several
services
appeared,
notably
groups
like
pinata
and
infuria.
Then
we
got
much
more
sophisticated
systems
for
doing
everything
like
doing
the
things
that
go,
that
unix
of
s
hoped
and
aspired
to
do
so.
Winifest
came
in
to
actually
address
a
lot
of
the
things
that
were
sort
of
left
out
of
of
unix
of
s
and
to
bring
capabilities
and
encryption
and
and
those
models.
I
guess
pierre
goes
also
had
the
tree,
so
pure
ghost
and
winifest
and
and
other
fission
systems
use
the
cryptotree
and
and
other
encryption
tooling.
A
Then
I
don't
know
if
at
this
time
or
another
point
in
time
in
the
future
was
when
ucams
came
about
and
ucans
are
really
cool.
I
think
they're
going
to
percolate
through
all
of
our
infra,
the
way
that
cids
cid's
percolated,
then
we
got
systems
like
fleeq,
which
started
building
like
super
easy
to
use.
A
We
also
got
a
bunch
of
larger
scale
data
systems,
mostly
around
blockchain
networks,
so
like
falcon
and
others
there's
a
number
of
other
blockchain
systems
that
I
think
primarily
use
kubo.
But
but
in
some
cases
I
think
they
have
forked.
It
falcon
ended
up
implementing
a
different
version
of
a
lot
of
the
same
systems,
because
the
tooling
ended
up
being
very
different,
like
syncing,
a
blockchain
and
building
a
blockchain
from
scratch,
using
all
the
cds
and
so
on.
Just
looked
like
a
very
different
problem
than
than
what
kubo
was
solving.
A
So
we
got
lotus
and
venus
and
friends.
Then
we
got
estuary
as
a
way
to
like
bridge
the
lotus
and
friends
ended
up
so
far
away
from
kubo
and
that
interop
between
those
seemed
extremely
difficult.
I
think,
even
today,
they
don't
quite
interop,
which
is
the
the
bane
of
our
existence
and
we're
getting
things
like
estuary
and
other
systems
to
help
bridge
those
gaps
and
both
kubo
and
lotus
and
friends
are
getting
closer
and
closer
to
each
other
and
along
the
way.
A
A
You'll
hear
more
about
utica
later
in
the
week.
It
might
be
a
good
system
to
build
ipfs
implementations
with,
and
I
think
this
doesn't
quite
work
yet,
but
we're
getting
saturn
soon,
which
is
a
cdn
style
ipfsnow,
which
is
kind
of
like
a
tiny
gateway,
but
imagine
a
a
double-ended
gateway
where
you
just
kind
of
stack,
a
bunch
of
little
gateways
on
top
of
each
other,
and
you
can
do
standard
http
traffic
through
them
or
grassing
traffic
cool.
A
But
the
really
big
breakthrough
came
when
http
clients
stopped
being
demons
and
separate
systems.
That
kind
of
built
the
whole
thing
end-to-end
but
had
explored
the
surface
area
and
had
warped
the
the
application
domain
enough
that
they
could
actually
become
very
small
lightweight
libraries
to
be
included
into
programming
language
runtimes
and
that's
when
the
web
really
exploded.
It's
when
you
got
all
kinds
of
application
systems
that
were
able
to
embed
web
functionality
in
all
kinds
of
applications,
but
you
couldn't
quite
do
this.
A
I
don't
think
you
could
have
ever
done
something
like
this
before
those
layers
in
between,
so
I
think
we're
kind
of
headed
in
the
same
direction.
So
we
had
go.
If
you
fast
in
jsiphos
at
the
beginning,
then
we
had
you
know
a
set
of
like
different
versions
of
those
systems
to
tune
them
for
different
applications.
Then
we
got
like
totally
different
implementations
of
the
same
set
of
ideas
and
I
think
the
the
big
breakthrough
here
is
going
to
be
wasm
or
that's.
A
I
think
is
where,
where
the
future
is-
and
it
remains
to
be
seen
whether
lipidop
will
be
able
to
work
in
this
environment
or
whether
ipfs
will
need
to
like
just
work
over
whatever
transport
exists,
whether
that's
ipfs
or
sorry,
http
or
or
something
else
so
yeah.
I
encourage
you
to
like
spend
some
time
this
week.
A
Thinking
about
this
problem,
because
I
think
that's
where,
where
some
of
the
feature
lies,
so
some
ideas
for
implementations,
ipvs
wasn't
already
kind
of
beating
the
horse,
you
could
imagine
a
very
simple
implementation,
that's
kind
of
like
node
or
deno,
which
just
has
a
wasm
runtime
and
code
loading
by
cid.
Just
think
of
that
as
a
very
simple
implementation.
If
you
have
dynamic
linking
by
cid,
you
can
have
modules
that
then
load
all
implementation.
A
All
the
rest
of
an
implementation
out
of
a
library
or
out
of
packages,
so
you
could
ship
an
ipfs
implementation.
That
is
just
that
little
run
time
with
code
loading
and
the
standard
library
of
some
packages.
You
can
pull
out
all
the
network
transports.
You
need
all
the
file
system
abstractions.
You
need
everything
else
so
that
you
could
end
up
with
a
super
portable
runtime
that
could
work
in
extremely
low
power
environments
too.
A
You
could
have
things
like
hypervisor
with
vm
workers,
so
think
of
like
wasm,
laminas
or
or
js
lambdas
and
containers
and
vms,
and
so
on.
All
of
this
content
addressed
and
snapshotted,
so
you
can
take
the
state
of
the
program
at
any
point
in
time
you
could
think
think
of
ipfs
over
http,
so
you
can
like
get
and
put
ipfs
over
cids
or
or
the
car
files.
A
I
think
this
actually
works
already
today,
but
I
don't
know
if
it's
been
like
canonicalized
or
blessed
anywhere,
but
I
think
a
bunch
of
tools
already
effectively
do
this.
We
could
have
a
rust
implementation
for
mobile.
I
think
most
of
the
groups
that
I've
been
trying
to
do
mobile
so
far
have
been
doing
it
with
go.
It
is
very
difficult.
A
Go
is
not
a
great
language
for
mobile,
yet
we
could
try
tiny
go,
which
is
an
embedded
systems,
oriented
thing,
but
it's
not
as
mature
as
I
think
this
is
where
a
rust
implementation
dedicated
for
mobile
could
make
a
huge,
huge
impact.
Something
that
I've
been
thinking
about
for
the
last
couple
of
years
is.
Could
we
do
something
like
a
decentralized
secure
version
of
software
defined
networking
in
peer-to-peer
could
like
software-defined
networking
totally
changed
the
networking
world
by
making
it
dramatically
easier
to
to
orchestrate
massive
scale
networks?
A
So
could
you
do
something
like
that
in
this
environment
and
make
it
secure
and
make
it
safe
and
make
it
so
that
you
can
write
a
program?
And
you
can
reason
about
what's
supposed
to
run
where
so
that
it
doesn't
kind
of
give
too
much
power
to
some
some
party
or,
if
you
can't
do
that,
then
just
make
it
in
inside
of
a
single
trust
domain.
A
A
We
can
then
start
thinking
about
like
services
and
nodes
and
so
on
that
are
part
of
the
network
that
are
not
necessarily
full
client,
clients
or
or
application
servers
things
that
are
meant
to
be
part
of
the
network
and
and
serve
some
purpose
like
indexers,
so
think
of
very
large
scale
index.
There's
like
100
terabyte
to
10,
petabyte,
scale,
content
routers.
A
You
could
take
those
full
things
and
replicate
them
around
the
world
and
offer
really
low.
Latency
content
address
delivery
and
you
can
have
basically,
if
you
get
these
like
full
replicas
around
the
world,
you
could
do
routing
in
you
know,
10
to
20
milliseconds,
as
opposed
to
you
know.
Currently,
today
we
do
like
hundreds
of
milliseconds
to
several
seconds.
A
You
could
also
think
about
building
indexers
or
content
routers
as
actual
proper
internet
backbone.
Routers,
like
you,
can
think
of
deploying
some
implementation
to
the
os's
that
internet
routers
use
or
to
fpgas
directly
what
it
would
look
like
to.
Could
we
could
we
just
do
that
now?
Could
you
start
building
content
routers
out
of
those
systems
and
get
some
like
super
fast
well-scaling
system?
A
Could
you
do
ivfs
with
remote
operations
like
uconns
for
off
and
so
on?
Maybe
you
can
already,
and
maybe
winfs
already,
does
this
we'll
hear
more
later?
Could
you
do
things
like
use
utico,
like
this
consensus
engine,
this
hierarchical
consensus,
engine
to
create
services
like
pinning
services
and
name
services
and
indexers
and
so
on?
Could
you
start
blending
zero
knowledge
proofs
into
ipfs?
Could
you
start
like
reasoning
about
some
of
the
computation,
some
of
the
routing
operations
or
some
of
the
selector
operations,
and
so
on?