►
From YouTube: State of Kubo - Gus Eggert
Description
Kubo (formerly go-ipfs) is the reference implementation for the protocol, and drives the vast majority of IPFS traffic. Hear where Kubo is headed next.
A
Hey
everyone
I'm
Gus
Eggert
I
mean
a
core
maintainer
of
Kubo
and
an
ipfs
Steward
of
protocol.
Labs
Kubo
is
a
go
implementation
of
ipfs.
It's
also.
The
first
implementation
of
ipfs
that
Juan
made
in
2014
kubo's
ux
is,
is
really
geared
towards,
like
CLI
usage,
so
mainly
tracks
like
power
users
and
people
who
are
comfortable
using
terminal
stuff.
A
Also,
importantly,
Kubo
is
really
geared
towards
being
like
a
developer
platform
to
build
other
applications.
So
Kubo
has
like
an
RPC
API
for
every
CLI,
command
and
I.
Believe
there's
like
191
CLI
commands
last
time.
I
checked,
so
it
has
a
really
extensive
API
that
that
ranges
from
like
the
lowest
level
in
Libya
p
through
ipld
and
all
the
way
up
to
the
high
level
ipfs
apis.
A
All
the
like.
The
core
components
of
Kubo
are
also
usable
as
external
libraries.
If
you're,
trying
to
like
build
your
own
applications
on
top
of
the
Kubo
code
base,
without
necessarily
using
Kubo
and
there's
a
lot
of
end
user
applications
and
critical
infrastructure
running
on
Kubo,
so
yeah
I
showed
this
in
the
in
the
in
the
intro
presentation
out
there.
But
I
love.
A
This
commit
big
things,
have
big
things
have
Small
Beginnings,
so
one
of
the
one
of
the
benefits
of
Kubo
being
the
first
implementation
is
that
the
code
is
like
super
battle
tested.
It's
been
run
for
eight
years
right
and
on
critical
infrastructure
which
weeds
out
a
lot
of
bugs,
and
because
it's
been
around
for
so
long,
it
has
a
huge
amount
of
features
that
it
supports.
Some
of
the
cons
of
that
obviously
comes
with.
A
It's
it's
like,
there's,
always
pressure
to
move
forward.
So
it's
hard
to
go
back
and
clean
up
things,
so
yeah
Kubo
used
to
be
called
go
ipfs
for
anyone
who
is
has
been
around
for
a
while,
you
might
know,
go
ipfs
and
not
Kubo
they're
the
same
thing.
We
renamed
it
to
sort
of
give
to
sort
of
free
up
the
namespace
of
ipfs
for
other
implementations.
A
Yeah
one
of
the
one
of
the
benefits
of
using
go
is
that
within
protocol
Labs,
the
go
ecosystem
is
really
active.
A
lot
of
the
libraries
that
we
depend
on
such
as
lip
P2P
ipld,
have
really
excellent.
Go
support
and
go
itself
is
really
easy
to
learn
and
build
stuff
in
which
is
important
for
why
Kubo
exists,
which
I'll
get
into
in
a
minute.
A
A
A
Kubo
yeah,
like
I,
was
saying
before
there's
a
extensive
CLI
for
Kubo.
One
of
the
design
principles
we
have
is
like
extreme
customization
but
keeping
same
defaults
so
like
you
can
basically
just
start
up
a
Kubo
node
it'll
work,
but
if
it
doesn't
work
for
your
use
case,
there's
probably
a
bunch
of
knobs,
you
can
turn
to
configure
it
to
work
for
whatever
it
is
you're
trying
to
do,
and
power
users
love
Kubo
too,
because
new
features
tend
to
land
in
Kubo
first,
so
it
which
can
be.
You
know
trade-offs
of
that
too.
A
We've
got
bleeding
edge
features
they
may
or
not.
Work
out
in
the
long
run,
like
I
said
before,
there's
an
RPC
API,
so
there's
lots
of
other
programming
languages
that
have
implemented
this
RPC
API.
So
you
can
do
stuff
with
ipfs
from
your
language
of
choice
without
necessarily
having
to
re-implement
the
entire
thing
from
scratch.
A
And
there's
a
there's,
a
plug-in
system
which
a
lot
of
people
use,
for
example,
to
implement
custom
data
stores
like
if
they
want
to
store
their
their
ipfs
node
data
somewhere
else
like
a
remote
like
a
maybe
a
postgres
database
or
Amazon
S3,
or
something
like
that.
You
can
just
Implement
a
really
simple
little
interface,
plug
it
into
Kubo.
Now
all
your
all,
your
your
data
is
being
stored
somewhere
else,
so
yeah
all
that
feeds
into
what
our
goals
moving
forward
are
with
Kubo.
A
So
we
want
Kubo
to
to
provide
the
best
technical
foundation
for
enabling
people
to
build
ipfs
products
and
experiments
as
quickly
as
possible,
so
we
really
biased
towards
like
development
speed.
So
you
know
we're
willing
to
trade.
For
example,
I
talked
about
portability
earlier,
with
the
go
run
time
like
that's
a
trade-off
that
we
make
in
order
to
make
it
faster
to
build
stuff.
A
So
there
are
certain
use
cases
that
we're
not
going
to
focus
on
like
embedded
stuff,
but
there
are
some
things
we
won't
trade
off,
which
are
security
and
performance,
because
Kubo
runs
on
such
critical
infrastructure
But.
Ultimately,
we're
trying
to
enable
experimentation
and
catalyze
the
community
of
all
the
other
implementers,
and
so
to
do
that.
You
know
extreme
customization,
we're
we're
going
to
really
focus
on
shipping
experimental
features,
working
with
researchers,
to
try
out
new
protocol
ideas
and
also
might
do
much
better
at
removing
failed
experiments.
A
A
A
There's
still
some
extension
points
for
Kubo
that
are
missing.
This
is
something
we're
working
on
now,
such
as
content,
routing,
there's
not
an
easy
way
to
tell
Kubo
to
do
its
content
routing
somewhere
else.
So
we've
got
some
stuff.
That's
almost
landed
to
let
Kubo
do
its
content,
routing
out
of
process
there's
also
some
parts
of
Kubo
that
are
not
actually
reusable
like
the
Gateway
HTTP
Handler,
because
it's
locked
away
and
it's
really
hard
to
consume
using
Kubo
as
a
library
could
have
way
better
DX.
A
So
we've
got
like
hundreds
of
repositories
that
roll
up
into
Kubo
across
protocol
labs
and
some
of
those
libraries
have
like
various
versions
that
are
incompatible
with
each
other.
So
you
end
up
with
this
like
awful
dependency.
Hell,
there's
like
sometimes
it's
hard
to
figure
out
what
library
to
use,
because
we've
got
like
multiple
libraries
and
they
have
various
feature,
sets
that
they
support
and
because
of
that
contributing
to
Kubo
can
be
hard,
sometimes
because
there's
a
lot
of
repos.
A
A
The
DHT
has
been
neglected
for
a
long
time,
so
we're
going
to
start
working
on
protocol
improvements
for
the
DHT
and
we're
going
to
consolidate
all
of
kubo's
libraries
into
one
repo
and
one
library
and
treat
that
as
a
first-class
citizen
to
enable
other
implementers
to
build
on
top
of
them
much
more
easily
they're
all
going
to
be
versioned
together
and
start
removing
unused
and
broken
features
and
other
changes
we're
making
we're
moving
our
roadmap
back
into
GitHub.
So
everyone
can
see
what
our
plans
are
and
comment
on
them.