►
From YouTube: IPFS Implementations - Gus Eggert, Brendan O’Brien, Alan Shaw, Alex Potsides, & Juan Benet
Description
Lightning talks from the lead maintainers of key IPFS implementations and the creator of IPFS.
A
So
yeah,
what
is
Kubo
kubo's?
The
first
ipfs
implementation,
Juan
Bennett,
made
the
first
commit
in
2014
in
Kubo,
which
started
not
only
Kubo
but
ipfs,
which
is
pretty
cool.
Kubo
ZX
is
centered
around
a
CLI,
so
the
users
of
Kubo
tend
to
be
power.
Users,
but
Kubo
also
serves
as
a
platform
for
other
Developers,
so,
like
all,
the
core
functionality
of
Kubo
is
separated
out
into
libraries
that
go
developers
can
use
to
build
other
applications.
A
So
that's
led
to
a
lot
of
end
user
applications
and
critical
infrastructure
that
runs
on
Kubo,
such
as
ipfs
desktop,
which
is
a
graphical
application
for
ipfs.
The
Brave,
the
brave
web
browser
embeds
Kubo
inside
of
it
to
Route
ipfs
traffic
through
Kubo
ipfs
cluster,
which
orchestrates
Kubo
nodes
to
provide
massive
amounts
of
data
to
the
ipfs
network,
the
ipfs.io
gateways,
which
serve
billions
of
requests
per
week
in
traffic.
All
these
things
are
powered
by
Kubo.
A
So
kubo's
ultimate
goal
is
to
provide
the
best
technical
foundation
for
quickly
building
new
ipfs
products
and
experiments.
We
do
that
by
biasing
towards
development
speeds,
so
whenever
we
need
to
make
trade-offs,
we
tend
to
trade
off
towards
development
speed,
but
we
will
not
trade
off
security
and
performance
since
Kubo
is
so
critical
to
to
so
much
infrastructure.
A
So,
but
ultimately,
we
want
to
enable
fast
experimentation
and
catalyze
the
the
ipfs
community
through
extreme
customization.
So
throughout
the
stack
and
Kubo,
all
of
the
components
can
be
customized
and
extended.
We
ship,
Cutting,
Edge
experimental
features
to
users
and
gather
feedback
from
the
experiments
and
remove
the
ones
that
didn't
work
we
share
and
we
share
those
learnings
from
those
failed
experiments
with
other
implementations
and
based
on
all
of
that,
we
provide
reference
implementations
of
ipfs
specs
through
the
ipip
process.
B
Iro
is
efficient
ipfs
for
the
whole
world
right
now
it
is
a
new
implementation
of
ipfs
that
we've
been
rewriting
in
rust
from
a
number
of
people
at
number,
zero
and
a
bunch
of
community
contributors
right
now,
it's
kind
of
like
what
do
you
mean
by
it
right
now?
Well,
back
in
ipfs
thing,
which
is
an
implementers
conference
that
we
had
in
July,
we
promised
a
release
of
iro
in
Q4
of
2022.,
it's
Q4
2022.
B
And
I'd
like
to
invite
a
special
guest
up,
I,
think
dig
my
co-founder
and
CTO,
and
the
person
who
personally
ported
bit
Swap
all
seven
or
eight
thousand
lines
of
it
into
rust
and
then
made
it
function,
should
come
up
and
push
this
button
run
dig
run.
We
don't
have
time
run
so
the
Wi-Fi
in
here
has
been
a
little
shoddy.
Do
you
want
to
do
the
honors?
B
Hey
all
right,
high
five
that
was
worth
not
sleeping
for
like
a
month
right,
okay,
so
I'm
happy
to
announce
to
you
iro
version
0.1.0.
It
actually
worked.
It's
up
on
GitHub
right
now.
I
hope
check
it.
But
what
is
it?
It
is
a
new
implementation
of
ipfs,
but,
most
importantly,
it
actually.
The
thing
we
have
gotten
with
this
0.1.0
release
is
actual
interop
with
Kubo,
so
you
can
bit
swap
with
Kubo
nodes.
B
Our
first
release
is
aimed
at
the
cloud,
but
it
actually
works
great
on
your
laptop,
so
well,
I'm
running
it
right
now,
sketchy
right,
but
like
it's
working,
we're
building
it
for
efficiency,
releasing
to
multiple
platforms.
There's
lots
to
talk
about.
We
have
some
great
numbers
that
this
one
isn't
really
focused
on
our
numbers,
but
we're
very
happy
with
our
throughput
in
terms
of
requests
per
second
on
small
files.
B
We
are
a
very
measurement
measurements,
focused
organization,
so
we're
not
going
to
lie
to
you
when
we're
slower
right
now,
if
you
want
to
do
10
microwave
files
use
Kubo,
it's
faster
ad
speed
similar
deal
we're
getting
there,
but
the
thing
that
we
really
want
to
highlight
for
this
release
is
we
have
a
release.
That's
on
the
board.
It's
a
brand
new
implementation
of
ipfs
ready
just
in
time
for
ipfs
camp,
and
we
cannot
wait
to
get
you
to
try
and
kick
tires
on
this
thing
so
that
we
can
productionalize
it.
B
C
I'm
Alan
nice
to
see
you
and
meet
you
and
see
you
elastic
ipfs,
all
right,
Alaska,
it's
a
new
type
of
ips
ipfs
peer.
It
leverages
Cloud,
Cloud
providers
whose
infrastructure
has
been
proven
to
be
web
scalable,
so
Alaska
first
is
free
and
open
source.
It
looks
like
an
elastic
band
ball
because
it's
elastic
ipfs
all
right.
C
So
this
is
this
well
missing
an
emoji,
but
fine
that'll
do
so
well,
let's
go
Fest
does,
is
it
separates
its
read
and
write
pipelines,
so
the
computers
that
are
that
are
accepting
data
are
not
the
same
computers
that
are
also
reading
the
data.
So
we're
trying
to
kind
of
avoid
this
problem.
Where
we've
got
this
super
busy
node,
that's
doing
lots
and
lots
of
things
and
it
just
yeah.
C
It's
busy
cool,
so
wow
I
should
not
just
use
so
many
emojis
right,
so
elastic
copy
Fest
doesn't
actually
have
loads
to
say
about
about
rights.
Essentially
data
kind
of
comes
in
it
comes
into
a
service
worker
that
scales
out
pretty.
Well,
that's,
that's!
You
know
like
lambdas.
If
you
know
that
what
that
is,
that
kind
of
thing-
and
that
goes
straight
into
a
that
little
square-
there
is
a
bucket-
it's
a
simple
storage
bucket
and
we
put
car
files.
C
We
accept
car
file,
uploads,
which
are
serialized
dags,
let's
go,
and
then
what
this
is.
Where
elastic
ibfest
comes
in
it,
what
it
does
is
it
gets
informed
that
there's
a
new
car
in
the
bucket
and
it
maintains
an
index
of
of
the
blocks
in
that
car-
the
bite
offsets
exactly
in
that
car
and
which
car
they
are
in
so
yeah.
C
So
when
you
do
byte
range
requests,
you
can
actually
extract
multiple
blocks
at
a
time,
so
you
don't
have
to
do
separate
requests
for
every
block.
So
that's
that's
really
cool
and
there
we
go
yeah.
Alaska
ipfs
is
maybe
the
largest
ibfest
peer
that
has
ever
existed.
It
currently
serves
nearly
5
billion
blocks,
which
is
pretty
rad,
and
it
does
that
with
the
help
of
the
network
indexes
and
the
network
indexes
help
us
allow
all
of
those
blocks
to
be
available
on
the
DHT.
C
C
As
you
can
see,
Zero
almost
zero
percent
of
the
time
cids
were
not
to
be
no
provider,
records
are
being
found
for
for
cids
in
the
DHT
and
when
they
were,
it
was
just
kind
of
by
chance
that
someone
else
had
it
and
then
they
got
turned
on
and
it
all
went.
It
went
up
to
almost
100
all
the
time
and
it's
basically
stayed
there
ever
since.
So
that's
super
good
news
and
we're
very
happy
with
with
that.
C
So
more
bad
emojis,
but
what's
the
future
hold
for
us
well,
like
I,
said
bunch
of
optimizations
I
wanna.
We
we
need
to
get
that
spatial
locality
thing
when,
where
we
send
requests
for
bike
ranges
that
that
include
multiple
blocks,
we
need
to
sort
that
out.
We
want
to
do
some
sort
of
prefetching
like
elastic
hobbyfest
is
kind
of
network.
I
o
bound.
It
doesn't
have
access
to
a
solid-state
drive
like
other
IBS
implementations.
So
what
we
can
do
is
when
we
receive
a
message
for
some
blocks.
C
The
architecture
for
elastic
ivfs
should
be
transferable
to
any
cloud
provider
and
basically,
as
long
as
they
can
provide
The
Primitives
that
it
needs
so
we'd
like
to
see
more
infraris
code
repos
for
other
Cloud
providers,
so
like
cloudflare,
are
really
close
to
providing
all
the
things
we
need
yeah.
So
hopefully
that
soon
last
thing
there
is
multi-region
would
be
rad
to
actually
run
this
thing
in
multiple
reasons.
Maybe
multiple
instances
we'll
see
how
that
works
out.
So
that's
funtime's
future
thanks
very
much.
C
If
you
want
to
know
more,
then
please
come
to
my
talk.
It's
called
five
billion
blocks
and
then
there's
another
talk
from
Paolo
from
their
form
on
horizontal
scaling
of
web
free
system
to
the
sky
so
and
that's
in
the
iprofs
implementers
track.
Thank
you
very
much
for
listening
and
I
hope
to
talk
to
you
all
soon.
All
right,
bye.
D
My
name's
Alex,
but
CDs
I
am
aching
brain
on
the
internet,
I
look
after
the
JS
ipfs
implementation,
which
I'm
going
to
talk
about
very
briefly,
because
we're
running
out
of
time,
jsonfest
is
the
second
oldest
ipfs
implementation,
I
believe
the
first
commit
we
actually
looked
at
it
in
the
replay.
The
other
day
was
2014..
It's
been
going
for
a
long
time.
D
D
D
D
If
you
look
at
the
stats
for
the
the
bootstrap
nodes,
every
ipfs
node
when
it
starts
up,
connects
to
some
kind
of
bootstrap
node
in
order
to
get
onto
the
network
from
from
the
ones
that
PL
maintains.
Just
under
12
of
the
network
is
JS
ipfs.
So
it's
an
enormous
number
and
we're
out
to
redeveloping
it.
D
So
we've
had
seven
releases
in
the
last
seven
major
releases,
I
should
say
in
the
last
12
months
and
lots
and
lots
of
little
patch
releases,
we've
shipped
so
DHT
implementation,
We've
shipped
to
yamex
implementation
for
for
better
multiplexing,
we're
investing
in
the
connectivity
stories.
So
we've
shipped
away
an
experimental
web
transport
transport
which
allows
connecting
from
browser
nodes
directly
to
to
Kubo
nodes
at
the
moment.
D
D
This
one's
different
from
the
existing
webrtc
implementation
in
the
there's,
no
centralized
signaling
server.
It's
going
to
be
using
circuit,
relay,
V2
and
and
finding
Network
appears
to
do
handshake
exchanges
and
that
kind
of
thing
I'm
hacking
on
a
on
a
quick
transport
right
now
for
node,
which
is
gonna,
be
very
exciting
and
we
want
to.
We
want
to
make
ipfs
more
modular.
So
part
of
the
whole
theme
of
this.
D
D
We'll
go
into
more
detail
about
that.
At
my
talk
in
the
implementations
track
later
this
afternoon,
we
should
all
you
should
all
totally
come
to
we're
looking
to
grow
the
team,
so
we're
hiring.
So
please
please
come
and
talk
to
me
if
you'd
like
to
help
just
develop
this
incredibly
interesting
technology
and
in
an
amazingly
undisuited
language
for
it.
D
E
We'll
even
talk
briefly
about
ipfs
implementation,
so
we've
reached
a
massive
scale
with
apis
we're
somewhere
in
the
10
million
to
100
million
end
users
weekly
across
a
bunch
of
applications.
We
have
hundreds
of
thousands
of
weekly
active
nodes
that
we
can
see
in
the
DHC,
there's,
probably
many
more
hundreds
of
thousands
in
a
bunch
of
applications
that
are
not
connected
to
the
broader
Network.
There's
hundreds
of
protocols
relying
on
ipfs
many
of
them
massive
scale
networks,
there's
thousands
of
applications,
thousands
of
business
businesses
and
so
on.
E
So
it
is
definitely
past
time
that
we
build
a
very,
very
robust
ecosystem
of
many
implementations.
The
ones
you
heard
from
today
are
a
sample
of
a
bunch
of
the
amazing
work.
That's
going
on
and
I
want
to
remind
everybody
that
protocols
and
implementations
evolve
and
they
tend
to
be
supercharged
by
composability
and
programmability.
The
HTTP
story
was
that
you
know
it
started
with
httpd
a
very
simple
Daemon
process,
and
so
on.
E
So
we
got
a
bunch
of
different
HTTP
client
implementations,
then
HTTP
server
implementations
at
first
it
were
very
complex.
They
got
simpler
and
simpler
and
simpler
and
easier
and
easier
and
easier,
as
people
really
finally
understood
how
to
drive
HTTP
use
across
the
web,
and
so
that
led
to
a
massive
explosion
of
the
web
that
we
have
seen
today.
E
So
ipfs
is
following
a
similar
trajectory.
We
started
with
a
set
of
implementations.
We
evolved
them
over
time
with
a
bunch
of
slightly
different
use
cases
we
now
went
through
and
renamed
them,
so
there's
no
canonical
main
implementation,
but
they
said
many
different
implementations
across
use
cases.
We've
gone
through
our
kind
of
Apache
and
nginx
moment,
and
now
we're
entering
the
new
era
where
composability
and
programmability
with
programming
languages
is
going
to
lead
to
some
massive
explosion.
We
don't
know
what
this
is
going
to
look
like.
E
E
So
there's
a
ton
of
sessions
today
learn
a
ton
about
how
to
implement
things,
how
to
use
things,
how
to
giving
feedback
and
so
on,
and
then
carry
that
forward
in
a
bunch
of
different
conferences
related
to
with
us
and
online
workshops.
There's
a
number
of
groups
forming
online
and
so
that
we
now
are
developing
the
proper
open
source
working
groups.
So,
if
you're
interested
in
working
on
some
component
of
ipfs,
if
you're
interested
in
working
on
some
implementation
join
a
working
group
or
you
know,
propose
one
or
create
one
together.