►
From YouTube: Ceramic: A Platform for Smart Documents and Decentralized Identity on IPFS - Michael Sena
Description
What is the Identity Index? Michael Sena explains how this evolution in decentralized identity is going to be a standards game changer in the IPFS ecosystem.
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
A
You
know
like
why
sort
of
the
you
know,
file
or
content
management
systems
are
are
broken
today
and
that's
either
because
they're
hosted
on
tv
or
server
or
sort
of
their
static
files
that
live
somewhere
on
the
decentralized
web,
and
so
we
basically
wanted
to
create
a
new
model
for
content
which
we're
calling
smart
documents
and
it's
all
completely
built
peer-to-peer,
and
so
what
smart
documents
do
are
really
moves,
content
beyond
databases
and
static
files.
So
you
can
basically
turn
your
files
into
dynamic
objects
that
get
a
permalink
that
never
changes.
A
They
have
verifiable
versions.
So
you
can
update
these
files
completely
permissionlessly.
You
can
give
them
each
each
file,
its
own
capability
set
and
logic.
So
you
can
do
cool
things
like
you
know,
define
the
rules
that
govern
what
constitutes
a
valid
update
to
that
content
in
really
dynamic
and
interesting
ways
which
I'll
jump
into
it
also
opens
up
unlimited
collaboration
and
sort
of
incomposability
that
we're
sort
of
used
to
as
a
as
it
relates
to
blockchains
in
web3.
A
And,
lastly,
you
get
improved
security
and
trust,
so
you
can
really
guarantee
the
state
of
your
document
to
others
in
a
completely
transparent
and
decentralized
way,
and
so
state
management
is
something
that
that's
really
been.
What
we've
been
trying
to
get
to
with
the
notion
of
smart
documents?
How
can
we
build
a
state
management
system
or
a
version
control
system
for
content
that
lives
completely
decentralized,
but
that
can
be
customizable
and
so
some
of
the
features
of
of
smart
documents
sort
of
some
of
them.
A
I've
covered
at
a
high
level,
but
basically
every
document
is
identified
by
a
permalink
and
it
never
changes.
Each
document
gets
verifiable
versions
that
can
be
explicitly
referenced.
So
you
can
reference,
you
know
a
doc
id
and
you
get
the
latest
state
of
a
document
or
you
can
reference
a
doc
id
with
a
with
sort
of
a
query
version
parameter,
and
you
get
only
that
explicit
version
as
it
was
at
that
point
in
time,
and
every
document
can
be
defined
by
a
schema.
A
You
can
configure
each
document
so
each
individual
bit
of
content.
You
can
choose
where
to
persist.
Your
content,
which
can
be
you
know
like
filecoin,
for
example,
or
a
sql
server
you
can
choose
which
blockchain
to
use
for
your
timestamps
and
timestamps
are
actually
what
we
use
to
explicitly
form
versions,
and
so
you
can
choose
to
anchor
those
updates
on
ethereum
bitcoin,
any
other
blockchain
platform,
and
you
can
configure
privacy
settings
so
you
can
basically
encrypt
documents
and
whole
in
part
just
records
sort
of.
A
However,
you
want-
and
you
can
manage
the
sharing
of
that,
if
private
and
lastly
logic
so
you
can
basically
define
a
set
of
rules
that
enforce
the
update
behavior
of
your
documents.
You
could
say
my
document
can
only
be
updated
if
the
owner
updates
it
or
all
of
the
owners
update
it
or
one
of
the
owners
updates
it
or
you
can
even
write
scripts.
That
say
automatically
update
this
document.
A
If
the
state
of
document
b
changes
and
update
this
document
to
reflect
that,
so
you
can
really
start
to
code
content
and
program
content
in
a
new
way
completely
permissionlessly
and
also
documents
can
emit
events
that
cause
other
things
to
happen,
such
as
a
node.
You
know
pinning
your
image
content
or
persisting
at
the
file
point
touching
back
on
composability
that
we
covered
so
really
what
this
you
know,
network
of
verifiable
programmable
information
allows.
Is
you
know
all
this
information
can
be
trusted?
A
You
know
documents
can
link
other
documents
to
create
chains
or
mappings
of
linked
content,
so
you
can
form
document
graphs
and
each
document
to
some
extent
already
does
this,
because
a
schema,
for
example,
is
defined
as
a
ceramic
document,
and
then
you
reference
that
schema
in
the
document
you're
creating
saying
this
document
is
going
to
conform
to
the
schema,
and
so
each
document
already
is
just
a
mapping
of
two
a
schema
and
a
document.
But
you
can
then
map
actual
documents
together
which
I'll
go
into
and
aggregations.
A
So
you
know,
for
example,
if
you
wanted
to
build
a
decentralized
logging
platform
or
commenting
system
on
ceramic,
you
could
basically
have
each
user
individually
post
their
own
con,
their
own
comments
to
their
own
document
and
have
another
document
that
just
runs
a
script
that
listens
to
all
the
documents,
with
a
specific
tag
or
something,
and
it
will
just
aggregate
that
up
into
one
script
and
last
and
integrations
so
it
kind
of
ceramic
is
really
this
rules
and
content
management
engine
that
exists
on
top
of
a
bunch
of
other
technologies,
so
identity.
A
A
Yeah,
like
I
mentioned,
storage
you
just
in
a
ceramic
node,
you
can
plug
in
a
persistence
provider
and
that
can
be
filecoin.
You
know
we
got
a
grant
from
filecoin
to
both
integrate
filecoin
keys,
with
the
did
for
identity
and
integrate
filecoin
persistence
as
an
option
to
a
ceramic
node.
So
you
can
actually
persist
your
content
in
a
decentralized
way
or,
if
you're
already
using
centralized
servers.
You
can
do
that
too.
A
It
obviously
offers
different
guarantees
about
the
documents
that
are
persisted
that
way,
but
the
protocol
is
sort
of
agnostic
to
persistence.
Compute.
If
you
have
documents
that
run
scripts,
you
can
invoke
code
that
lives
on
a
server
somewhere
or
anywhere
else,
and
lastly,
you
can
plug
in
any
blockchain
for
anchoring-
and
I
just
covered
a
lot
of
this,
but
I'll
just
focus
in
on
some
of
the
ipfs
pieces,
so
sort
of
separated
from
the
file
coin.
Persistence.
A
How
we
actually
use
the
ipfs
stack
is
that
every
record
in
a
document
so
document
consists
of
a
chain
of
records,
they're
all
ipld
objects
and
we
use
lib
p2p
to
sync
updates
around
the
nodes
in
the
network.
So
it's
a
gossip
network
where
you
know
one
node
can
manage
the
state
of
a
document
and
others
can
can
gossip
about
it
and
also
replicate
it
if
they
want
the
network.
A
The
interesting
thing
here
with
ceramic
is,
unlike
blockchains,
there's
no
global
state,
so
instead
we
opted
for
doc
state,
so
there's
only
state
per
document
and
they
form
doc
chains,
because
you
have
a
series
of
records
that
are
anchored
but
there's
no
global
state
between
documents.
So
you
know
in
the
same
way
as
ipfs
works.
A
If
you
don't
persist
your
content
to
file
coin
or
you're,
the
only
node
running
that
document
and
you
shut
your
computer
off
or
you
delete
that
content
like
it
can
be
gone
because
the
the
doc
state
is
only
maintained
as
long
as
the
network
maintains
it,
and
this
provides
scale
because
content
there
will
be
so
much
content
in
the
world
that
you
can't
run
a
global
state
machine
on
that,
and
so
this
allows
ceramic
to
be
run
and
really
resource
constrained
environments
such
as
browsers
and
other
things,
without
a
bunch
of
other
layers
built
on
top,
and
I
covered
a
lot
of
this
stuff
already.
A
But,
interestingly,
if
you
look
at
the
diagram
like
different
nodes,
which
are
the
triangles
can
run
different
configurations,
so
one
is
running
bitcoin
and
ethereum
anchoring
and
lid
p2p
and
ipld
and
other
ones
just
running
bitcoin,
anchoring
other
ones
just
running
ethereum
anchoring
and
there's
an
overlap
in
that,
but
there's
no
global
state
how
documents
work
really
quickly.
So
you
have
you
know
a
series
of
records,
there's
a
genesis
record.
Then
it
gets
anchored
on
a
blockchain.
Then
you
submit
one
or
multiple
signed
records.
A
Then
it
gets
anchored
on
a
blockchain
and
you
get
an
explicit
new
version
and
then
a
couple
more
update
records
happen
and
then
you
get
a
new
anchor
which
forms
a
new
version
and
because
we
use
blockchains
for
anchoring,
we
can
do
thing.
We
can
guarantee
the
state
at
versions,
and
so
this
is
really
important
for
decentralized
key
management
and
trusted
content.
A
Where
you
know,
if
I
remove
an
owner
from
a
document,
I
don't
want
that
owner
to
be
able
to
update
that
document
and
no
amount
of
subjectivity
and
consensus
is
allowed
in
that
case,
and
so
we
have
strict
ordering
with
blockchain
and
earliest
anchor
wins
and
doctypes
are
really
the
rules
engine
for
each
document.
When
you're
creating
a
document,
you
specify
the
doctype
three
doctypes
come
out
of
the
box
with
the
node.
You
can
also
just
write
your
own,
which
people
are
already
doing,
but
tiles
are
just
json
stores.
A
You
can
store
any
arbitrary
json
content
in
there
great
for
schemas
things
like
profiles,
like
blog
posts
messages.
Three
id
is
a
did.
Sys
is
a
did
method
native
to
ceramic,
so
a
decentralized
identity
system
with
secure
key
rotation
account
links
are
documents
which
link
your
did
to
on-chain
cryptographic,
accounts
or
network
accounts
somewhere
else
and
writing
your
own.
We
already
have
people
in
the
community.
A
Writing
verifiable
claims
doctype,
so
you
can
create
and
verify
claims
according
to
the
w3c
standard
for
those
and
also
someone's
working
on
a
script
doctype
as
part
of
hack
fs.
Actually,
both
of
these
are
part
of
hack
fs
and
the
script.
Doctype
is
doing
the
aggregation
that
I
talked
about
before.
So
you
could
build
a
commenting
system
that
one
document
is
aggregating.
All
the
the
contents
of
a
whole
bunch
of
documents
owned
by
the
users
themselves,
it's
available
as
a
full
javascript
client
or
you
can
use
it
over
an
http
api.
A
Both
apis
are
exactly
the
same,
so
sort
of
like
ipfs
would
work
and
some
things
being
built
on
top.
So
we
recently
have
been
doing
a
bunch
of
standards,
work
around
identity
on
ceramic,
because
ceramic
is
really
a
great
platform
for
not
only
managing
decentralized
identifiers,
but
when
you
think
about
identity
and
what
that
needs
to
be
in
the
decentralized
web.
Identity
really
is
an
index
of
all
of
your
resources.
A
Whether
those
are
your
profiles
or
your
peer-to-peer
databases
that
live
on
a
server
somewhere,
such
as
textile
databases
or
orbit
databases
or
your
files
stored
on
filecoin
or
your
social
graph
that
might
live
somewhere
or
various
other
things,
and
so
right
now
in
the
decentralized
web.
There's
no
single
place
to
query
and
discover
all
of
the
resources
associated
with
a
given
identity,
and
these
resources
exist
across
all
sorts
of
platforms,
and
so
idx
aims
to
solve
that
and,
like
I
said,
it's
fully
interoperable
with
any
blockchain
and
any
storage
system.
A
But
it
forms
this
mechanism
for
discoverability.
This
is
the
architecture
of
what
it
looks
like,
and
each
of
these
boxes
are
ceramic
documents,
so
you
have
a
did.
It
could
be
any
did
and
it
points
to
the
root
index
document
which
just
contains
mappings
from
like
profiles
to
the
profiles
index,
which
is
its
own
document,
and
in
the
profiles
index,
you
might
find
mappings
from
basic
to
location,
which
may
be
a
ceramic
dock.
Id
for
the
basic
profile
of
that
did.
A
Interestingly,
in
collections
are
sort
of
your
aggregations
of
user
data
usually
created
by
an
application,
and
so
those
are
defined
by
a
definition
which
consists
of
a
set
of
data
stores
with
explicit
schemas
to
say
I'm
using
a
textile
thread
and
it
uses
this
schema
and
I'm
using
an
orbit
store
and
it
uses
the
schema
and
a
ceramic
document
that
uses
the
schema.
A
Let's
say
your
app
consists
of
those
three
data
sources.
You
define
that
in
a
definition
which
gets
stored
in
the
collections
index
and
that
maps
to
a
reference
which
contains
user
specific
information
about
that
definition.
So
my
textile
thread
id
is
this
and
it
lives
at
this
hosted
service,
endpoint
and
my
access
controller.
Is
this?
And
so
really?
If
you
look
up
a
did,
you
can
find
its
root
index.
A
A
A
Alpha
devnet
is
available.
Now
you
can
start
playing
with
ceramic
already.
Clay
will
come
out
in
a
month.
It
has
just
some
improvements
to
it,
including
the
use
of
dag
jose,
which
is
a
new
standard
for
signing
and
encryption
for
json
web,
that
we
got
a
grant
from
ipfs
and
ethereum
to
build
we're
doing
that
along
with
textile
the
go
or
the
js
implementation
is
already
ready,
we're
looking
for
someone
to
build
the
go
implementation.
A
So
if
you're
interested
in
this,
please
reach
out
we're
looking
to
to
hire
someone
to
to
write
that
go
version
and
mainnet
will
come
out
and
mid.
Q4
here
are
some
resources.
A
Our
discord
is
there
I'll
also
drop
a
like
a
link
to
it
in
the
chat,
because
I
know
it's
not
human
readable
find
us
on
twitter,
we're
on
ceramic
network
on
github
and
a
lot
of
the
standards
I
talked
about,
including
doctypes,
schemas
idx
and
all
sorts
of
things
are
being
written
out
as
cip,
so
they
can
be
reused
and
shared
by
the
community
in
a
collaborative
way.
So
if
that's
interesting
to
you,
please
take
a
look
around
and.