►
Description
In this talk Michael Sena discusses the IDX identity protocol, which is the first platform-agnostic system for creating a logically centralized index of all user resources and data scattered across the web. Think decentralized, user-centric user tables!
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Join your local IPFS meetup to attend our next event: https://www.meetup.com/pro/ipfs/
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
A
So
idx
is
a
cross
protocol
identity
standard
tying
into
the
previous
talks
by
daniel
and
joel
idx,
which
we'll
dive
into
is
really
a
way
to
manage
the
entire
universe
of
user
information
or
or
just
generally,
information
about
a
did
in
a
decentralized
way,
and
it's
built
on
top
of
ceramic.
So
it
has
all
the
properties
that
joel
just
described
and
uses
ceramic
tiles
and
other
stream
processing
data
types
to
basically
create
the
system
and
all
right
so
for
fear
of
repetition.
A
Here
I
won't
go
into
detail
about
all
these
things,
but
sort
of
building
on
what
daniel
said.
Identity
is
really
the
aggregation
of
information
about
a
subject,
so
the
entire
universe
of
all
the
things
you
say
do
your
presence
online
and
in
web
2.
Obviously,
we
have
app
specific
identifiers
that
require
you
know,
server,
side,
authentication
and
in
a
traditional
you
know
relational
database
model
if
you're
using
dynamodb
or
something
you'll.
A
Probably
you
know
build
a
user
table,
except
these
are
all
just
fragmented
in
app
silos,
so
they
can
really
only
map
to
other
data
resources
produced
by
the
user
as
they
interact
with
that
single
application
and
they're
not
designed
for
interoperability.
So
they're,
you
know,
they're
tied
to
the
one
tech
stack
implementation
that
that
application
chooses
and
they
actively
discourage
discoverability
of
this
information
by
outsiders.
A
They
keep
it
safeguarded
because
that's
their
business,
but
in
web
3
it
sort
of
aims
to
flip
that
model
from
app
silo
to
user
silo
and
the
pieces
of
that
are
open
identifiers.
So
did's
like
daniel
and
joel
talked
about
with
sort
of
you
know:
client-side
authentication
it
could
be
server-side
but
sort
of
client-side
as
the
starting
point
for
decentralization.
A
And,
ideally
you
have
this
unified
did-centric
index
of
information
and
resources
associated
to
that
user
or
that
identity.
Ideally,
this
index,
you
know
maps
to
resources
anywhere,
because
you
know
there
are
different
data
producers
and
consumers.
So,
as
a
user
interacts
with
app
a
app
a
might
be,
storing
data
directly
in
file
coin
or
app
b
might
be
storing
data
in
text
style.
A
App
c
might
be
storing
data
on
a
centralized
data
store
somewhere,
and
the
aim
is
to
make
all
that
data,
interoperable
and
discoverable
in
a
single
place,
a
unified
location,
independent
from
any
technology
that
any
single
application
implements,
and
I
won't
have
to
go
through
this
so
thanks
daniel.
But
the
building
block
is
dids,
really
critical
to
sort
of
understand
that
these
are
decentralized
identifiers
registered
in
some
decentralized.
A
You
know
ledger
or
data
platform,
where
this
data
is
independent
of
any
third
party
and
these
identifiers
and
their
resulting
documents
that
they
represent
are
truly
decentralized
because
everything
sort
of
builds
from
that,
and
so,
if
we
think
about
you,
know
the
design
goals
of
really
what
one
wants
to
achieve.
When
designing
a
decentralized
identity
standard,
we
can
see
them
on
the
list
here
and
so
the
first
one
is
really
just
flexibility.
A
Sort
of
making
the
standard
agnostic
to
any
particular
technology
stack
that
a
given
application
developer
might
choose
to
deploy
on.
So
it's
ideal
that
this
standard
works
with
any
did
method
know
whether
it's
ion
you
know
being
run
by
microsoft
or
element.
The
other
implementation
of
side
tree
or
three
id
did
and
some
other
did's
native
to
ceramic,
like
it
shouldn't
matter,
because
these
dids
will
come
from
all
over
the
place,
it
should
work
with
all
authentication
methods
and
key
pairs.
A
So
you
know
being
able
to
control
one
identity
from
n
number
of
sign
in
methods,
whether
that's
a
blockchain
key
pair
in
a
client-side
wallet
or
a
social
login
managed
by
a
service
on
a
server.
They
should
all
be
able
to
control
the
root
identifier
which,
from
that
you
generate,
you
know
the
signatures
and
the
encryption,
which
enables
attribution
of
content
and
and
control
of
information
and
should
work
with
all
data
storage
technologies,
formats
and
locations.
So
whatever
you
want
to
build
on
whatever
wherever
you
want
to
deploy
it
shouldn't
matter
discoverability.
A
So
this
is
really
the
key
piece
to
building
sort
of
this.
This
data
index,
where,
instead
of
the
app
solid
model
where
we
have
today,
you
know
moving
towards
a
user
silo
or
user-centric
model.
It's
important
that
we
begin
to
describe
data
semantically
versus
describing
it
like.
Oh,
it's
data
from
app
a
or
data
from
app
b,
because
app
c
might
not
like
care
or
know
that
you
know
app.
A
and
b
are
both
blogging
platforms,
and
so
I
need
to
know
which
other
apps
a
user
has
used.
A
When
I'm
querying
this
information,
it
should
be
described
by
the
data
itself
like
by
the
shape
of
the
data,
the
schema
some
metadata
and
description
so
that
it's
more
interoperable.
It's
not
tied.
You
don't
need
to
know
all
of
the
other
apps
that
are
also
using
the
standard
in
order
to
consume
data
that
wasn't
created
by
your
application,
and
this
should
all
be
organized
in
one
logically
centralized
location
and
it's
logically
centralized
because
it
exists
in
one
place,
but
it's
on
a
decentralized
network.
A
So
it's
you
know,
sort
of
physically
decentralized
but
logically
centralized
and
it
should
be
privacy
preserving.
So
this
system
should
be
able
to
support
public
and
private
information
as
daniel
mentioned,
and
really
the
the
concept
of
pseudonymity
and
progressive
identity
needs
to
be
prevalent
when
designing
it.
A
You
can't
build
an
identity
standard
that
has
it
has
a
requirement
for
like
a
meet
space
id
or
like
a
government-issued
legal
identity
to
use
and
onboard,
but
rather
all
identities,
sort
of
start,
pseudonymous
and
empty,
and
depending
on
what
sort
of
information
the
user
adds
to
them
as
they
interact
with
apps.
This
identity
begins
again
begins
to
gain
meaning
over
time.
As
it's
used
and
it's
up
to
the
user
to
decide
what
sort
of
information
they
want
to
add
to
this
identity.
A
Some
of
them
could
end
up
taking
on
the
shape
of
legal
identities,
maybe
that
same
user
has
a
different
identity
that
they
begin
to
form
into
a
different
sort
of
like
persona.
You
know
we're
not
limiting
one
user
to
one
idx,
but
rather
sort
of
keeping
it
open,
so
it
can
be
used
in
as
many
ways
as
desirable
and
it's
important
that
these
have
standard
interfaces.
So
you
know
common
a
common
way
to
read
and
write.
Information
from
this
index
makes
things
interoperable.
A
This
index
idx
data
structure
should
be
sort
of
as
the
first
principle,
because
then
it's
really
controlled
by
the
users
and
not
by
a
third
party
or
a
server
that
if
it
goes
down
all
of
your
data
and
routing
information,
is
now
gone,
even
if
it's
for
a
period
of
minutes
and
scalability.
So
the
infrastructure,
the
decentralized
infrastructure
it's
built
on,
needs
to
be
able
to
scale
to
be
able
to
support
it,
which
is
sort
of
why
we
deployed
idx
on
ceramic
and
a
quick
intro
to
how
actually
works.
A
A
It's
an
ion
did
so
it's
you
know
anchored
in
bitcoin
on
the
ion
protocol
and
network
and
they
both
have
a
corresponding
index,
and
even
though
the
did
documents
that
daniel
talked
about
he
showed
they
have
public
keys,
used
for
signature,
verification,
encryption
and
also,
additionally,
service
endpoints.
The
nice
thing
about
ceramic
and
idx.
A
Is
you
don't
actually
have
to
register
the
index
in
the
did
document
as
a
service
you
could
for
redundancy,
but
ceramic
has
this
deterministic
property
where,
if
you
know
the
did-
and
you
know
you're
looking
for
its
index,
you
can
deterministically
query
for
this
index
and
the
ceramic
protocol
will
resolve
and
return
the
index
for
the
user
without
needing
to
actually
establish
a
link
which
is
critical
because
there's
so
many
different
did.
Methods
having
like
a
common
way
to
plug
them
in
might
not
always
be
feasible.
A
So,
given
a
did,
you
can
always
deterministically
generate
what
its
index
is
and
return
the
current
state-
and
here
you
see
two
users,
and
so
next
the
developer
will
create
a
schema,
publish
that
to
ceramic
in
a
tile
and
we'll
take
that
ceramic
stream
id
and
plug
it
into
a
definition
and
then
deploy
that
definition
on
ceramic
as
a
tile,
and
the
definition
basically
is
the
semantic
description
of
a
resource.
And
so
here
you
see
some
metadata.
Let's
assume
that
it's
a
basic
profile.
A
It
has
some
description,
a
universal
profile
and
it
has
a
schema.
So
this
serves
the
the
stream
id
of
this
definition
serves
as
a
key
in
the
index
and
as
a
developer.
I
only
need
to
create
a
definition
once
and
I
can
use
it
for
n
number
of
users,
so
in
user,
one
on
the
top-
and
these
are
two
on
the
bottom-
that
same
stream
id.
A
Both
of
their
indexes
and
now
as
a
user
user,
one
comes
to
my
app
they
plug
in
some
profile
information.
It
happens
to
be
satoshi,
they
have
an
ipfs
image
and
they
have
a
description
and
at
that
point
using
the
idx
api.
When
you
create
this
record
it,
the
idx
library,
automatically
publishes
the
definition
stream
id
and
the
record
stream
id,
which
is
a
separate
stream
into
your
index.
So
now
you
have
this
map
from
stream
id
of
definition
to
stream
id
of
record.
A
So
you
have
information,
stored,
semantically,
organized
and
now,
when
user
2
comes
the
same
definition
stream
id
is
is
a
key
in
their
index
and
they
create
a
separate
record
which
is
its
own
stream,
which
contains
their
profile.
So
now
you
have
thousands
of
users
of
your
app.
They
all
build
on
one
common
data
definition
and
each
of
the
corresponding
data
records
are
stored
separately
in
streams
and
in
these
records.
I
think
it's
important
to
call
out.
A
They
can
either
directly
contain
data.
Like
the
example
I
just
showed
of
the
basic
profile
you
can
just
dump
that
json
data
in
a
record
and
it's
sort
of
self-contained
or
you
can
use
records
as
sort
of
jump
off
points
or
routing
mechanisms
to
external
storage.
So
the
record
in
that
case
would
just
contain
you
know
a
uri
and
potentially
some
other
metadata
which,
when
resolved,
would
enable
you
to
route
to
some
external
to
idx
source
of
information,
and
that
could
be
other
ceramic
documents.
A
A
You
could
point
to
textile
data
stores
or
orbit
data
stores,
other
centralized
versions
or
even
on-chain
contracts
and
so
sort
of
serving
as
this
technology
independent
way,
you
can
use
records
as
sort
of
data
stores
or
pointers
to
additional
data
stores,
which
sort
of
all
serve
to
organize
information,
and
idx
is
more
than
just
about
users
as
daniel
and
joel
both
said,
if
it
can
be
represented
by
a
did,
it
can
have
an
idx.
So
you
know
for
the
case
of
people.
A
So
you
can
take
the
did
seed.
You
can
encrypt
it
with
some
blockchain
account,
let's
say
and
store
it
in
a
record
and
you're,
storing
an
array
of
effectively
encrypted
seed
material,
and
so,
as
a
user
you
know,
uses
their
meta
mask
to
sign
into
an
app
that
app.
Can
then
decrypt
the
did
seed
in
an
iframe,
that's
secure
and
protected.
A
We
are
building
one
called
3d
connect
which
allows
users
to
sort
of
authenticate
their
did
from
all
of
their
blockchain
wallets
people
are
using
it
for
profiles
and
social
graphs,
user
generated
content
like
blog
posts
and
photos
and
user
settings.
So
you
know
maybe
a
user
says
I
want
to
persist
all
my
files
to
this
specific
powergate
instance.
That's
running
filecoin,
and
so,
instead
of
the
app
itself,
you
know
running
a
powergate
instance
for
all
of
its
users.
A
Data
users
can
specify
their
own,
so
they're
sort
of
bringing
their
files
and
their
persistence
with
them
from
platform
to
platform.
So
they
can
have
one
universal
building
where
you
know
maybe
they're
being
billed,
and
they
subscribe
to
this
specific
backup
provider
that
is
now
portable
across
all
these
interfaces.
A
A
That's
really
hard
one
because
sort
of
agreeing
on
all
of
the
standards
for
all
of
the
data
formats
and
how
to
interpret
the
data
in
a
did
document
seems
extremely
difficult,
and
so
those
standards
are
going
to
be
impossible
to
achieve
for
the
entire
data
that
is
represented
by
the
digital
world
and
so
having
some
way
to
describe
definitions
and
semantically.
Organizing
it
outside
the
bounds
of
the
did
document
is
important.
A
Additionally,
did
documents
need
to
be
kept
super
lightweight
because
they're,
probably
one
of
the
most
synced
things
like
every
time
you
go
to
an
app.
They
need
to
sync
your
did
document,
and
so,
if
that
document
just
keeps
growing,
the
sync
time
increases
and
it
bloats
that
document
away
from
the
critical
information
which
is
really
just
the
signature
keys.
Like
your
public
keys
for
signatures
of
encryption,
some
say
you
use.
A
Even
if
it's
replicated
so
relying
on
decentralized
infrastructure.
To
be
that
first
jump
point.
And
then,
if
you
choose
to
route
to
a
secure
data
store
from
idx
to
store
a
subset
of
your
information,
that
you
want
to
keep
super
encrypted
and
private
on
a
server
seems
like
a
better
approach,
so
it
should
be
like
dids
idx,
then,
whatever
hosted
data
source
you
would
want,
rather
than
going
directly
from
did
to
hosted
data
store
and
yeah.
You
can
get
started
with
this
stuff
today.
A
So
ceramic
has
a
javascript
full
node,
which
can
run
in
browser
or
client-side
or
an
http
api,
and
for
authentication
you
can
authenticate
your
did
with
all
kinds
of
blockchain
wallets
that
your
users
already
have
using
through
id
connect,
or
you
can
natively
integrate
a
did
provider.
If
you're
trying
to
do
something
more
complex,
an
idx
is
a
javascript
sdk,
so
you
can
drop
it
right
into
your
app
client
side
and
it
works
and
yeah
you
can
check
out
the
docs
developers.idx.xyz.
A
Our
blog
at
ceramic
network
has
a
lot
of
good
content
and
tutorials.
If
you're
looking
to
play
around
and
if
you're
interested
in
trying
these
things
out
ceramic
is
on
test
nets.
You
can
just
go
ahead
and
start
building,
but
if
you
want
to
move
your
app
to
production
on
these
systems,
I
would
encourage
you
to
sign
up
for
the
early
launch
program
that
will
sort
of
that
we're
accepting
applications
for
now
and
will
officially
go
live
in
a
little
more
than
a
month.