►
From YouTube: What is IPLD Anyway? - Mauve Signweaver
Description
This talk was given at IPFS Camp 2022 in Lisbon, Portugal.
A
My
name
is
Moth,
my
pronouns.
Are
they
them,
and
today
I'm
going
to
be
talking
about
this
thing
called
interplanetary
linked
data
and
why
you
should
consider
using
it
in
your
decentralized
applications,
so
interplanetary
linked
data
or
ipld
is
data
that
is
content
addressed
and
is
linked
wow,
who
could
have
thought?
So,
let's
look
at
what
that
actually
means
in
more
detail
at
the
core
of
everything.
Ipld
is
the
ipld
data
model.
This
is
an
abstract
specification
for
the
kinds
of
data
that
can
be
represented
and
exchanged
in
this
system.
A
Everything
in
the
ipld
data
model
extends
from
this
core
type
called
a
node
which
can
basically
stand
in
for
any
of
the
other
ones.
There's
scalar
types
like
null
integers
floats
strings
and
bytes
there's
also
recursive
types
like
lists
that
can
contain
any
other
node
or
maps
that
can
map
a
string
to
any
other
node.
We
also
have
a
special
data
type
called
a
link
which
can
link
to
another
node,
which
you
might
also
have
seen
around
called
a
sid
or
CID.
A
So,
together,
these
data
types
can
be
used
to
represent
most
kinds
of
data
that
you
might
see
in
an
application
now,
although
the
data
model
is
useful
to
represent
whatever
you
want
in
memory,
we
also
need
a
way
to
represent
it
on
disk
for
or
for
sending
over
the
network,
and
that's
the
role
that
codecs
play.
They
take
nodes
in
the
abstract
data
model
in
memory
in
your
application
and
turn
them
into
blocks
that
can
be
referenced
and
sent
around.
A
So
with
this,
if
you
have
the
bytes
and
a
CID,
you
can
verify
that
the
bat
bytes
match
the
CID,
and
you
also
have
a
way
to
know
how
to
decode
it.
This
means
that
if
you
get
a
block
anywhere
in
your
system
that
supports
ipld,
you
can
decode
it
and
run
it
in
your
application,
regardless
of
what
the
backing
bytes
are.
So
if
you
have
it
encoded
in
Json,
seaboor,
Ben
coded
it
all
behaves
pretty
much
the
same
and
is
transparent
to
your
application.
A
The
CID
is
also
how
we
do
the
linking
portion
of
linked
data.
So
whenever
you
want
to
link
to
another
node,
you
can
point
to
its
Cid.
In
this
example,
we
can
see
how
I
get
the
CID
of
this
first
block
of
data
after
encoding.
It
then
I
can
get
another
CID
of
another
block
of
data
that
links
to
the
first
one,
and
so,
with
this
final
link,
we
have
a
tree
or
a
graph
of
linked
data.
A
This
type
of
data
structure
is
called
a
merkeldag
and
it's
used
all
over
the
place
in
distributed
systems,
since
it
has
nice
properties
like
being
content,
addressable,
immutable,
verifiable
and
traversable,
so
merkeld
eggs
are
used
in
all
sorts
of
places
like
pretty
much
all
of
the
blockchains
in
all
of
the
peer-to-peer
protocols,
pretty
much
anywhere
where
you
want
kind
of
like
decentralized
content
and
dressable
data,
which
is
probably
the
sorts
of
things
that
are
relevant
here.
So
speaking
of
the
traversal,
that's
also
something
that
ipld
can
do
for
you.
A
A
The
kind
of
naive
approach
to
traversing
data
is
to
just
write
code
that
will
get
the
individual
links
and
follow
them,
but
that
can
be
super
messy
to
write
and
instead
we
have
this
nice
syntax.
That
saves
a
lot
of
the
trouble
of
traversing
and
makes
it
easier
to
deal
with
deeply
nested
data.
A
So
the
next
bit
that
ipld
adds
is
the
concept
of
lenses
over
top
of
ipld
data.
This
is
also
probably
something
that
folks
are
less
likely
to
be
exposed
to,
on
average,
so
lenses
map
a
given
ipld
node
to
another
shape
of
ipld
node.
This
can
be
useful
for
verifying
contents,
making
data
more
legible
and
working
with
complex
data
types
in
ways
that
are
standard
between
applications
rather
than
needing
to
reinvent
them
each
time.
A
A
One
of
the
purposes
of
the
schema
spec
is
to
have
a
reusable
way
of
representing
ipld
data,
which
can
be
verified
across
different
applications
and
languages.
You
can
define
a
set
of
types
that
your
application
will
support
and
other
implementations
can
use
it
to
verify
that
they
are
correctly
generating
and
parsing.
Those
types
can
also
be
useful
as
documentation
for
your
data,
since
it
gives
you
a
quick
dance,
a
quick
glance
of
what
your
data
looks
like
without
having
to
decode
it.
A
A
What
you
can
do
with
representations
is,
you
can
say,
at
the
high
level,
in
my
application,
I'm
going
to
treat
this
as
a
struct,
but
when
I
am
encoding
and
decoding
From,
the
Block
I
want
to
represent
it
as
something
more
efficient.
For
example,
here
a
tuple
tuples
work
where,
if
you
know
the
order
that
values
in
an
array
are
going
to
be
and
how
they
map
to
some
string
Keys,
you
can
just
kind
of
skip,
adding
those
string,
keys
and
encode
it
more
efficiently.
A
So
finally,
some
things
are
hard
to
represent
in
the
declarative
approach
and
that's
where
Advanced,
Data,
layouts
or
ADLs
come
in
they're
a
lens
that
consists
of
specifications
for
how
to
structure
more
fancy
data
with
schemas
for
documenting
what
the
data
should
look
like
and
text
descriptions
on
how
to
construct
and
Traverse
these
data
structures
and
fixtures,
so
that
implementations
can
run
tests
against
those
implementations
to
make
sure
that
they
got
everything
right
currently
in
order
to
use
ADLs,
you
pretty
much
just
have
to
hard
code
Things
based
on
the
spec
in
your
application,
but
there's
some
reusable
implementations.
A
You
can
just
kind
of
import
in
most
languages
and
down
the
line
we
might
be
looking
at
using
webassembly
for
the
automatic
loading
and
decoding
of
these
Advanced
Data
layouts
examples
of
ADLs
are
the
hash
array.
Maps
try,
which
is
being
used
in
places
like
filecoin
to
efficiently
have
very
large
maps
of
key
value.
Data
for
representing
the
state,
or
also
a
new
spec.
That's
being
processed
right
now
called
prollytrees
probabilistic
B
trees,
which
is
a
useful
building
block
for
building
database
indexes,
so
I've
been
putting
all
of
this
together.
A
In
a
new
spec
called
ipld
urls,
this
is
built
on
top
of
the
URL
specification
that
you
might
be
used
to
in.
You
know,
website
links,
but
it
extends
the
origin
and
pathing
to
be
able
to
apply
lenses.
So
with
this
spec,
you
can
specify
that
a
given
CID
should
be
interpreted
automatically
with
an
ADL
like
a
hampt
or
to
say
that
at
some
point
in
your
graph
traversal,
you
want
to
start
applying
a
schema
on
the
data
in
order
to
automatically
parse
out
representations.
A
This
kind
of
gives
you
a
declarative
way
to
take
advantage
of
all
of
the
functionality
of
ipld
data
loading
without
having
to
dig
around
between
a
bunch
of
different
libraries.
So
it's
a
bit
of
an
experiment
at
the
moment,
but
we're
hoping
to
use
this
as
the
start
of
some
higher
level
apis.
This
is
also
something
I'm
working
on
getting
into
gateways
so
that
we
can
have
IPL
the
data
loading
be
a
first
class
citizen.
A
So
finally,
even
though
I
mentioned
earlier
that
Merkle
dags
are
great
and
immutable,
and
so
you
know
verifiable,
and
you
don't
have
to
worry
about
changing
things-
you
actually
do
want
to
change
data
over
time
in
most
applications
and
for
a
Content
addressable
treat,
and
it
can
actually
be
a
little
bit
difficult
to
write
the
code
to
Traverse
and
rebuild
nodes.
So
with
that
in
mind,
we
have
the
ipld
patch
spec,
which
is
based
on
the
Json
patch
spec.
A
The
way
it
works
is
you
can
have
a
set
of
operations
such
as
adding
removing
copying
which
acts
on
given
nodes
in
a
graph
using
these
paths
and
then
with
that
you
can
take
an
object.
For
instance,
here
I
have
Goodbye
cruel
world,
apply
some
patches
and
get
back
a
modified
version
of
your
object,
in
this
case
Hello
World.
This
is
a
simple
example,
but
in
very
deeply
nested
trees
and
in
very
complex
data
layouts.
It's
really
nice
to
have
this
as
an
option
in
order
to
make
application
development
more
simple
as
well.
A
A
So
that's
ipld,
baby.
The
nice
thing
is
that
you
can
use
as
little
or
as
much
of
this
as
you
want
for
your
applications,
and
a
lot
of
things
in
the
ipfs
ecosystem
will
have
a
dependencies
on
these
specs
one
way
or
another.
So
one
question
I
get
a
lot
is
what
is
ipld?
Is
it
ipfs?
How
do
they
even
relate,
and
the
thing
is
even
though
ipfs
uses
cids
and
codecs
under
the
hood?
A
It's
actually
a
little
bit
more
complex,
so
ipld
on
its
own
doesn't
determine
a
method
for
resolving
blocks,
whereas
ipfs
generally
uses
lib,
P2P
or
some
sort
of
HTTP
gateway
to
resolve
and
advertise
them
as
well.
Ipfs
focuses
on
a
different
data
model
called
Unix
FS,
which
represents
data
in
a
more
file
systemy
way
and
is
built
on
top
of
the
dagpb
Kodak
as
well
ipfs,
rather
than
having
the
straightforward
traversal
of
following
property
names
in
an
object.
A
Graph
uses
something
more
custom
that
again
takes
advantage
of
dagpb
and
its
file
based
approach,
so
ipfs
uses
some
ipld
things,
but
they're
actually
fairly
different,
and
so
one
cool
thing
about
ipld,
being
decoupled
from
ipfs
is
that
it
can
be
used
to
represent
all
sorts
of
linked
data
by
adding
new
codecs.
This
enables
things
like
linking
to
a
git
commit
from
ipld
using
the
regular
CID
interface
or
linking
to
bitcoin
blocks
linking
to
ethereum
Smart
contracts
or
nfts
or
linking
to
entire
bittorrents
trees.
A
All
in
the
same
way
and
what's
cool,
is
that
you
can
use
the
same
traversal
and
lensing
techniques
over
any
of
these
approaches
to
render
them
all.
You
really
need
to
interface
with
these
different
data
schemes
is
a
custom
link
system
that
knows
how
to
Res,
resolve
cids
for,
say,
a
Bitcoin
block
to
the
actual
data
or,
and
also
you
need
to
have
codecs
that
can
encode
to
and
from
all
of
these
native
types.
A
So
why
is
all
of
this
useful,
or
why
should
you
care
the
coolest
bit
to
me
is
that
it
makes
it
easy
to
have
interoperability
and
also
have
verifiability
built
into
the
systems.
A
This
is
a
nice
building
block
for
things
like
distributed
databases
or
peer-to-peer
and
blockchain
use
cases
where
you're
often
going
to
run
into
all
of
the
same
needs
from
your
code
base
and
rather
than
implementing
it
over
and
over,
you
can
reuse
ipld
across
all
of
them.
Ipld
also
gives
us
a
nice
bridge
between
peer-to-peer
and
content
address
systems
and
formats
like
rdf
or
activity
streams
which
have
a
long
history
of
ecosystem
growth
and
kind
of,
like
collaboration
between
a
bunch
of
different
groups
on
data
models.
A
So,
if
you're
making
a
distributed
application,
you
likely
care
about
a
lot
of
this
stuff
and
IPL.
The
is
a
tool
being
developed
to
serve
your
needs
so
now
that
we
all
know
some
stuff
about
ipld.
What's
going
to
go
next
for
ipld
as
a
tool,
we're
looking
at
growing
our
team
right
now
and
part
of
that
is,
we
want
to
improve
the
rust
implementation
of
ipld
so
that
we
can
support
use
cases
like
the
fvm
or
the
various
webassembly
things
that
are
starting
to
spring
up.
A
We're
also
going
to
be
updating
our
docs
and
making
them
more
accessible
to
have
a
more
straightforward,
onboarding
ramp
to
people
that
just
kind
of
want
to
get
started
with
the
tools
and
finally,
we'll
be
looking
at
offering
options
for
higher
level
apis
that
expose
all
of
ipfs's
power
to
or
iplds
powered
to
regular
users,
while
leaving
the
underlying
core
available
for
the
hardcore
developers.
That
really
need
it.
A
So
I
hope
this
has.
Given
you
a
better
view
of
what
ipld
is
and
why
you
should
care
about
it
and
I
hope
you
can
go
out
there
and
make
something.