►
From YouTube: What's up, What's new, What's next - Eric Myhre
Description
IPLD engineer from Protocol Labs, Eric Myhre, kicked off our November event by bringing the crowd up to speed on all of the latest developments within the realm of IPLD.
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
A
The
first
time
you
might
have
heard
of
ipld
could
have
been
several
years
ago.
Already
it's
a
project
that
comes
out
of
ipfs,
the
shared
prefix
ip
is
not
a
coincidence
and
we've
really
grown
the
project
a
lot
from
its
earliest
beginnings.
As
this
thing
that
came
out
of
ipfs,
so
I'm
going
to
talk
a
lot
about
that
transition.
A
A
So
a
million
years
ago,
ipfs
was
just
just
this
thing
that
stores
files
and
makes
them
globally
available,
which
is
really
cool
and
really
hard,
but
it
was
just
for
files,
so
the
first
step
of
generalizing.
This
was
ipld
started
as
being
this
thing
called
dag
pb,
which
is
short
for
directed
acyclic
graph
based
on
protobufs,
which
was
a
way
to
describe
large
blobs
of
binary
data
and
linked
together
into
tree
structures
and
and
so
go
from
there
and
be
able
to
address
those
tree
structures
in
this
globally
content
addressable
way.
A
A
A
We
also
have
the
ability
to
talk
about
binary,
byte
sequences,
big
large,
blobs
and
links,
by
which
I
mean
the
cid
structure
that
you're
probably
familiar
with
from
ipfs
already
so
with
this
general
data
model
concept,
ipld
is
no
longer
just
about
file
systems
and
opaque
blobs.
It's
about
structured
data.
A
A
An
abstract
syntax
tree,
but
it's
kind
of
without
the
s,
because
this
is
kodak
agnostic,
there's
no
single
syntax
of
serialized
data
that
you
need
to
worry
about.
The
ipld
data
model
can
actually
be
connected
to
dagpb,
like
we
talked
about
earlier
or
plain
old,
json
or
other
formats
like
seaboard,
and
really
any
codec
that
you
can
imagine
can
be
plugged
into
this
data
model.
We
even
have
bridges
to
other
content,
addressable
systems
like
bitcoin,
ethereum
and
really
awesomely
git.
A
So
what
kind
of
stuff
lots
of
stuff
the
most
common
thing
is
just
to
have
a
library
which
can
traverse
these
data
structures
programmatically.
That's
cool.
We've
also
built
higher
level
features.
On
top
of
this,
for
example,
something
called
selectors,
which
is
a
declarative
model
for
making
traversals
happen
I'll
get
to
that
more
later,
some
features
called
advanced
layout
schemas.
A
One
of
the
purposes
of
selectors
is
you
can
draft
one
of
these
up,
send
it
to
some
other
computer
in
a
network
and
ask
them
to
evaluate
the
selection
for
you.
They
could
then
stream
back
data
that
matches
and
you
could
evaluate
the
selector
yourself
as
well,
since
these
are
non-trained
complete
and
have
limited
power.
A
You
can
do
this
in
a
relatively
safe
way,
even
when
you
don't
necessarily
trust
the
person
sending
you
queries,
which
is
kind
of
cool
we're
using
features
like
this
to
develop
new
data
transports
like
graphsync
I'm
already
running
out
of
time-
and
I
have
eight
million
more
things
to
talk
about,
so
I'm
gonna
go
real
fast.
We
have
a
concept
called
adls.
This
is
short
for
advanced
data,
layouts
long
story,
short
sharding
is
now
a
feature
of
ipld.
A
You
can
implement
your
own
plugins
for
how
you
want
to
shard
data
and
make
it
appear
as
data
model
nodes,
so
like
the
same
maps
and
lists,
and
this
lets
us
have
transparent
pathing
even
over
really
large
started
data
structures.
This
is
something
that
ipfs
web
gateways
have
had
for
unix
of
sp1.
Now
we've
generalized
and
made
it
into
something
that
you
can
use
in
applications
with
your
own
special
logic.
A
Ipod
now
has
a
schema
language.
You
can
use
the
schema
language
to
define
types
that
have
semantic
behaviors,
structs
and
sometimes
unions,
enums.
Things
like
this
that
you're,
probably
familiar
with
from
other
type
systems,
you've
used
as
a
programmer
and
combined
with
this
type
specification
in
the
ipld
schema
language.
You
can
associate
a
representation
clause
with
this
type
clause.
This
describes
how
this
information
should
be
transformed
in
and
out
of
the
data
model,
and
thus
how
individual
codecs
should
proceed
to
represent
it.
A
A
A
If
you
have
a
document
which,
in
the
data
model
or
say
this
is
written
in
json
for
clarity,
you
have
a
list
and
it
just
contains
the
number
one
and
the
number
two
you
can
match
this
against
a
schema
that
has
some
named
type.
That's
a
list
of
integers.
Clearly
this
matches,
you
could
also
match
it
against
a
schema,
saying
it's
a
struct
with
two
fields
and
a
representation
of
tuple
mode.
A
You
can
also
use
multiple
schemas
to
attempt
to
match
the
same
data
and
use
this
to
construct
feature
detection,
we're
very
hopeful
that
this
will
let
people
build
decentralized
applications
in
a
flexible
evolvable
way
that
may
never
have
been
possible
before
we've
also
got
a
bunch
of
really
cool
new
tooling,
which
has
come
out
to
this.
Recently
we
have
syntax
highlighters,
courtesy
of
one
of
my
fine
colleagues.
A
A
We
have
schema,
auto
derivers.
This
is
something
that
is
actually
so
cool.
I
barely
understand
it.
This
is
again
coming
from
a
fine
colleague
named
rod,
something
that's
cool
with
this
optional
schema
system
is
you
can
take
data
that
has
no
schema
previously
associated
with
it
and
still
infer
a
structural
type
which
describes
it,
so
people
have
been
able
to
build
tools
that
do
this
automatically.
A
A
We
even
the
list
just
goes
on
and
on
have
bridges
to
graphql.
Why
not?
Another
colleague
has
built
this
system,
which
is
a
mostly
one-way
bridge,
from
ipld
schemas
to
graphql
ipl.
These
schemas
are
somewhat
more
expressive
than
graphql.
So
there
are
some
interesting
details
to
mine
with
this,
but
it
is
letting
us
write,
ipld,
schemas
and
use
graphql
visualization
tools,
as
well
as
submit
graphql
queries
against
apis,
which
then
transform
that
data
into
ipld
queries
and
do
the
thing
this.
This
is
just
so
cool
long
story
short
come
build.
A
Applications
with
ipld
cool
stuff
is
happening
over
here
and
I'll
leave
you
with
a
bunch
of
links.
If
you
want
to
know
more,
there
are
specs
repos,
where
I
think
probably
most
of
our
interesting
development
goes
on.
There's
also
docs
websites.
Here
the
development
team
on
ipld
hangs
out
in
irc.
This
is
also
a
bridge
to
matrix
if
you're
a
fan
of
that
sort
of
thing,
and
if
you
want
to
bug
me
elsewhere
on
the
interwebs
at
warp
fork
is
usually
my
handle
find
somebody
with
that
name.
It's
probably
me,
maybe
it's
the
internet.