►
From YouTube: DIDs without Blockchains - Implementing Peer DIDs in an Hour or a Day - Daniel Hardman, Evernym
Description
DIDs without Blockchains - Implementing Peer DIDs in an Hour or a Day - Daniel Hardman, Evernym
Decentralized Identifiers (DIDs) are like DNS without any registrars. They're a foundation of decentralized identity, and are relevant to most Hyperledger projects. They've been implemented on Hyperledger Indy as well as public blockchains like Bitcoin and Ethereum, and those implementations are important.
But just as the Lightning Network took Bitcoin transactions off-chain, and Plasma took smart contracts off-chain, we need a way to take DIDs off-chain. 99% of all the DIDs the world needs can be handled this way, with massive benefits for scale, performance, cost, and decreased complexity.
In this session, we'll explain how peer DIDs work, and show developers how they can get support for them in an hour or a day (depending on their circumstances).
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerGlobalForum2020 #Blockchain
A
A
My
thing
is
digital
identity
and
there
are
a
number
of
people
in
this
room,
I'm
sure
who
know
quite
a
bit
about
digital
identity
and
are
in
the
same
space
that
I
am,
but
there
might
be
some
people
who
are
here
from
general
blockchain
backgrounds
who
don't
know
what
it
did
is.
So
let
me
kind
of
go
into
that
for
just
a
minute.
A
A
did
is
a
kind
of
identifier
and
it's
proved
to
be
important
in
digital
identity
systems,
decentralized
identity
systems
and
you
can
think
of
it-
did
as
being
fairly
similar
to
a
UUID
there's
a
lot
of
similarities.
Actually
they
run
more
than
just
a
surface
level,
but
I
did
has
some
unique
properties
that
make
it
interesting
in
a
decentralized
identity
world.
The
first
one
is
that
it
has
this
property
of
cryptographic,
proof
of
control,
which
means
you
can
prove
who
owns
it.
A
A
You
can
always
decide
for
sure
who
owns
the
dead
because
of
the
cryptographic
control
property.
The
second
thing
about
it
did
that
makes
it
unique
and
useful
is
that
it
is
resolvable,
and
that
is
like
the
way
a
DNS
name
is
resolvable.
So
when
you
go
to
a
bank
or
whatever,
and
you
type
in
your
domain
name
in
your
browser,
you
know
your
browser
underneath
is
doing
this
resolution.
It's
turning
that
name
into
the
IP
address
that
it
needs
to
talk
to
well.
I
did
has
that
same
kind
of
property.
A
You
can
start
with
this
identifier
and
turn
it
into
an
endpoint
that
helps.
You
know
where
to
go
talk
to
the
owner
of
that
did,
and
so
that's
as
deep
as
I
want
to
go
for
people
who
don't
know
the
background
and
they're
just
coming
from
a
general
blockchain
background,
hey
I
just
wanted
to
make
sure
that
you
kind
of
had
a
little
bit
of
the
context
here.
Why
did
czar
interesting?
A
It's
a
person.
It's
an
IOT
thing:
it's
an
institution.
It
could
be
a
document
there's
all
kinds
of
things
that
could
be
identified
with
these.
Okay,
so
did
x'
as
an
interesting
building
block
are
defined
in
what
are
called
method
specs
there's
a
general
did
spec
it's
a
standard
and
it
says
here's
how
you
create
dids
and
here's
how
they
work
and
all
that
kind
of
stuff
you
would.
A
You
could
liken
that
standard
to
something
saying:
here's,
how
the
domain
name
system
works,
but
did
czar,
decentralized,
meaning,
there's
no
I
can
telling
you
how
to
do
things,
and
instead
what
there
is
is
a
way
for
you
to
say:
I'm,
gonna,
I'm
gonna
create
DIDS
this
way
and
register
that
way
into
a
larger
context,
so
that
other
people
can
find
your
dudes
and
know
about
them,
and
you
don't
need
anybody's
permission
to
do
that.
So
what
I'm
here
to
talk
about
is
a
way
that
you
can
do
that
without
using
block
chains.
A
Now,
if
you're
coming
from
the
blockchain
world,
you
might
say,
wait
a
minute.
I
think
you
just
described
an
interesting
problem
and
it
sounds
like
a
blockchain
problem.
Why
are
you
not
telling
me
how
I
can
do
this
with
block
chains?
And
the
answer
is
because
everybody
who
invented
DIDS
immediately
saw
that
block
chains
were
an
obvious
way
to
solve
this
problem
and
three
and
four
years
ago.
That
was
all
the
rages.
A
We
think
that
a
subset
of
DIDS
belong
on
block
chains,
so
the
blockchain
did
convergence
isn't
going
away,
but
it's
it's
becoming
more
specialized,
so
I'm
going
to
tell
you
how
we
took
some
of
the
principles
that
we
learned
in
the
world
of
blockchain
and
applied
them
to
the
problem
of
creating
dids,
but
we
took
it
off
the
chain.
Okay,
all
right!
That
was
a
long
time
on
one
slide.
I'm
gonna
go
faster
after
that,
okay,
so
here's
the
way
most
DIDS
are
created
and
managed.
Today
you
have
at
the
top
of
the
chart.
A
Okay
and
blockchain
is
a
great
way
to
do
that,
because
here's
a
global
source
of
truth
that
holds
that
information
so
when
Bob
creates
his
pairwise
did
I'm
using
a
word
there
that
I
just
introduced
pairwise
the
notion
that
this
is
the
did
that
Bob
and
Acme
want
to
use
with
each
other
each
one.
Each
each
party
in
a
relationship
creates
one
of
these
dudes
trades
it
with
the
other
party
and
says
here's
my
did
and
and
so
forth.
Okay,
they
go
register
that
stuff
on
the
blockchain.
You
can
now
go,
look
it
up.
A
Hopefully
that
makes
sense.
Okay,
now
what's
good
about
this,
is
that
you
have
all
of
the
properties
of
blockchain
about
being
it's.
You
know,
it's
tamper,
proof
and
it's
very
democratized.
Anybody
can
use
the
blockchain
to
register
stuff.
All
those
are
wonderful
properties,
but
there's
some
extra
stuff
that
a
blockchain
does.
That
makes
us
a
little
bit
troubled
if
Bob
and
Acme
don't
want
the
world
to
know
about
their
relationship,
but
it's
on
the
blockchain.
A
We
start
to
have
a
little
bit
of
discomfort.
Now,
of
course
you
can
encrypt
stuff,
and
you
know,
there's
various
other
things,
but
hopefully
you're
starting
to
hear
in
my
voice,
I'm
heading
in
a
direction
that
many
of
you
have
started
to
think.
Do
we
really
want
to
put
this
on
a
blockchain?
Maybe
not
you
know.
This
is
I,
think
a
familiar
kind
of
a
theme
that
we've
started
to
hear
at
conferences
like
this,
so
there's
also
scale
costs
and
security
and
privacy
and
performance
implications
to
doing
it.
A
This
way
and
again,
I'm
not
saying
that
all
dudes
belong
off
the
blockchain
I'm
just
saying
that
some
do
okay,
so
peer
dudes
is
a
recognition
that,
when
Alice
and
Bob
or
Acme
and
Bob
or
whoever
want
to
talk
to
each
other
and
it's
a
private
relationship,
it's
not
the
world's
business,
it's
Alice
and
Bob's,
or
Acme
and
Bob's
business,
and
because
it's
Acme
in
Bob's
business
they
create
these
dudes
and
who
do
they
have
to
tell
about
it
each
other
full-stop
end
of
statement.
There
is
no
need
for
the
world
to
go.
A
Look
that
up.
Not
only
is
there
not
a
need,
it's
not
even
a
desirable
quality,
and
so
in
a
peer
did
kind
of
a
mechanism.
What
happens
is
Bob
creates,
as
did
Acme
creates
it
did
they
tell
each
other
directly
about
their
deads
and
they
give
each
other
essentially
for
the
people
who
aren't
kind
of
did
people
here,
it's
like
giving
each
other
a
DNS
record,
an
a
name
record
or
a
cname
record,
or
something
you're,
giving
each
other
the
metadata
that
you
need,
so
that
if
you
ever
need
to
look
up,
my
did
well.
A
Here's
the
data
that
you
need
to
know
about
it,
and
that
gives
you
like
the
end
point
where
you
can
come
talk
to
me
on
the
internet
or
the
cryptographic
keys
that
you
can
use
to
prove
that
I'm,
really
the
person
I
say:
I
am
and
so
forth.
That's
the
basic
concept
of
a
peer
did:
okay,
I
mean
I,
think
maybe
I'm
gonna
stop
for
a
second
just
check.
A
Are
there
any
questions,
because
what
I
say
after
this
will
not
make
as
much
sense
if
I
lost
you
already,
you
feel
a
little
comfortable
with
this
okay.
So
how
do
you
actually?
Oh?
Well,
actually
let
me
sit
before
I
say:
how
do
you
do
this?
Why
do
you
do
this?
Well,
there's
a
lot
of
reasons
there.
I
won't
I
won't
read
the
slide,
but
these
are
the
same
reasons
that
a
lot
of
other
things
are
taken
off
of
block
chains.
Okay,.
A
Now
part
of
the
title
of
my
talk
was
I
was
going
to
tell
you
how
you
could
do
this,
how
you
could
actually
implement
peer
DIDS
in
a
very
short
timeframe,
so
what
comes
next
is
a
description
of
the
code
that
you
see
there
and
that's
the
full
length
of
code.
It's
about
97
lines
of
code
in
Python
to
implement
peer,
DIDS
and
97
lines
of
Python
could
probably
be
ported
to
your
favorite
programming
language.
Pretty
fast
I
haven't
done
it,
but
other
people
have
done
it.
A
There's
an
implementation
in
go
and
there's
other
people
working
on
in
other
languages.
So
it's
not
very
hard
to
implement
what
I'm
about
to
describe.
That's
the
main
point,
and
if
you
want
to
go
look
up
the
implementation,
that's
the
link!
Okay,
by
the
way
these
slides
are
uploaded
into
the
conference
stuff,
so
you
can
get
in
get
them
yourself
if
you
want
okay,
so
how
do
you
actually
create
a
peer
did?
Well,
what
you
do
is
you
create
a
did
document.
A
A
did
document
is
like
that,
a
name
record
or
cname
record
that
I
was
talking
about
it's
a
document
that
describes
what
are
the.
What
is
the
endpoint
for
this
did
what
are
the
cryptographic
keys?
That
will
verify
that
somebody
is
the
owner
of
it.
Did
you
create
this
document?
It's
a
JSON
document
and
you
omit
from
the
document
one
key
piece
of
information
and
that's
the
value
of
the
did
itself.
Normally.
That
document
would
have
the
value
of
the
did
inside
of
it.
B
A
This
is
a
little
bit
more
technical
breakdown
of
it
at
the
bottom,
you
see
an
actual
peer
did
value,
that's
the
string
on
the
bottom
line
of
this
diagram
and
up
at
the
top,
you
see
the
different
inputs
that
were
used
to
build
it.
Okay,
so
there's
just
a
prefix
that
did
peer
thing
that
just
comes
straight
through
the
numeric
algorithm
is,
in
this
case
algorithm
one
there's
several
different
ways
that
you
can
generate
these
numbers,
but
only
one
of
them
is
defined.
A
This
is
future-proofing,
so
if
you,
if
we
define
a
new
way
to
do
it,
there
could
be
an
algorithm
to
or
whatever,
and
then
we
have
to
transform
that
256
bit
number
that
we're
working
with
into
text
and
there's
a
algorithm
for
doing
the
transform
and
that's
Z
represents.
We
got,
did
pr1
Z,
and
then
you
got
the
blue
rectangle
after
it,
so
the
the
rectangle
after
it
is
a
base,
58
encoding
of
the
256
bit
number
and
the
rest
of
it
is
all
prefix
of
various
kinds.
A
Okay,
what
I've
just
described
to
you
here
should
feel
if
you're
a
programmer
like
oh
I,
get
it.
You
might
not
understand
all
the
reasons
why
we're
doing
it,
but
if
somebody
gave
you
this
diagram
and
the
context
I've,
given
you,
you
should
probably
estimate
that
you
know,
while
you're
eating
your
sandwich
at
lunch,
you
could
probably
write
a
function
that
could
generate
this
thing.
It's
not
very
hard,
it's
not
rocket
science.
A
So
one
of
the
things
you
could
do
is
you
could
say
well
I,
with
this
key
I'm
gonna
sign
stuff.
With
that
key
I'm
going
to
do
something
else,
you
could
kind
of
partition
out
the
different
things
that
the
keys
are
allowed
to.
Do
that's
what
that
authorization
section
is
I'm
not
going
to
get
into
it
in
great
detail,
but
basically
those
are
the
two
parts
and
I'm
omitting.
In
this
case,
this
minimal
doc
doesn't
have
any
endpoints.
A
A
A
Basically,
you
have
one
party
that
comes
up
with
part
of
some
information
and
the
other
party
comes
up
with
a
part
of
some
information
and
you
trade
it
and,
at
the
end,
you
you
both
end
up
knowing
a
secret
that
observers
on
the
outside
wouldn't
know.
Okay,
so
it's
not
an
overwhelmingly
complex
protocol.
Invite
you
to
go,
read
it
I'm
not
going
to
get
into
it
too
deeply.
The
other
option
is
just
use
any
other
channel
to
transmit
stuff,
and
you
could
do
that,
but
you
might
lose
some
properties.
A
So,
for
example,
if
you
come
up
with
your
did
documents-
and
you
transmit
these
on
a
TLS
session-
you
know
from
part
in
point
A
to
point
B
you're,
just
using
HTTP
and
TLS,
to
send
the
data
that's
great.
But
if
there
is
a
SSL
visibility
appliance
in
between
you,
you
could
have
a
man-in-the-middle
I
used
to
work
for
blue
coat.
Blue
coat
makes
appliances
like
that
they
do
exist
and
they're
used
all
the
time
by
most
of
the
large
companies
that
we
work
for.
A
If
you
work
for
a
small
company,
probably
not,
but
if
you
work
for
a
big
company,
probably
the
IT
department
at
that
company
is
running
one
of
those
appliances
so
that
they
can
check
to
see
if
there's
malware
in
the
encrypted
HTTP
traffic
and
stuff
like
that,
which
means,
theoretically,
a
malicious
sysadmin
could
be
in
between
you
and
could
pick
up
these
things
and
anyway.
So
that's
that's!
A
Basically,
you
get
the
right
regular
expression
which
is
given
to
you
in
the
peer
dude
spec,
and
you
stick
it
somewhere
and
you
go
check
to
see
if
the
fields
in
your
database
are
big
enough
to
hold
the
regular
expression
and
whatever
and
you're
done.
Okay,
that's
a
10-minute
job
layer.
Two
is
accepting
and
giving
static
peer
dudes
to
one
another.
Okay,
let
me
talk
about
the
difference
between
static
and
dynamic,
peer
dudes.
A
So
if
Alice
and
Bob
are
going
to
have
a
short-lived
relationship,
there's
no
point
in
having
a
fancy
mechanism
whereby
they
could
rotate
keys
and
change,
which
end
point
they're
using
and
all
this
other
stuff,
so
they
just
come
up
with
a
did
and
put
some
information
in
their
document
and
information
in
the
other
document
trade.
The
information
use
it
for
the
duration
of
that
interaction
and
then
throw
it
away.
Okay,
it's
ephemeral!
That's
a
static
peer
did
if,
on
the
other
hand,
Alice
and
Bob
have
a
long-running
relationship.
A
A
So
that
means
that
you
have
to
have
some
kind
of
dynamism
in
your
system.
It
needs
to
be
possible
for
Bob,
who
has
this
did
to
say
to
Acme,
hey
Acme,
I've
updated.
My
keys
and
Acme
needs
to
know
when
they
get
that
kind
of
communication
that
that's
a
legitimate
thing
and
not
a
hacker
telling
them
that
Bob
updated
his
keys.
Okay,
so
dynamic
peer
dudes
are
about
solving
that
problem,
and
many
problems
don't
actually
require
dynamic.
A
You
get
to
decide
if
you,
if
you
decide
to
implement
this
at
all
in
your
world,
whether
you
want
to
have
dynamic
peer,
did
support
or
only
static
peer,
didn't
support
up
to
you,
the
relative
that
call
them
over
there
on
the
right,
yeah
right
coding
time
to
implement.
This
is
just
you
know,
Daniel
taking
a
wild
swagat
thing.
So
there's
no
science
behind
this,
but
you
know
I,
think
a
regular
expressions,
kind
of
a
really
short
kind
of
a
thing,
the
except
static
and
give
static
features
at
layer.
A
Think
it
was
San,
Francisco
and
I
was
halfway
into
the
flight
when
I
started.
Writing
it.
So
it's
about
maybe
an
hour
worth
of
coding.
Now
I
have
an
unfair
advantage,
because
I
wrote
the
spec,
so
I
knew
what
was
in
there,
but
nonetheless
it's
not
I
said
two
to
six
hours
to
implement
this.
This
is
not
particularly
hard
stuff.
Okay,
layer,
three
is
far
more
ambitious
and
it's
ambitious
because
you
have
to
have
a
prerequisite.
You
have
to
understand
how
to
speak.
Something
called
did.
Comm
did.
Comm
is
basically
a
communications
mechanism.
A
You
can
think
of,
did
comm
being
a
little
bit
like
TLS,
except
peer
to
peer
and
not
certificate
oriented,
although
did
comm
can
work
over
HTTP
or
over
HTTP
just
fine,
but
it's
a
rough
analogy.
So
if
you
have
that,
then
it's
probably
a
weak
to
implement
the
synchronization
protocol
that
lets
you
correctly
support
peer
dudes
at
a
dynamic
thing,.
A
What's
the
status
of
this
effort
just
a
little
bit
of
context
here,
sometimes
we
hear
cool
things
at
conferences,
and
we
wonder
you
know
like.
Is
this
pie-in-the-sky
or
is
real
or
whatever
there's
an
official
spec
for
the
peer
did
effort?
It's
a
pretty
good
spec,
it's
30
or
40
pages
long.
It's
been
reviewed
by
a
number
of
people
about
a
dozen
experts
and
it's
been
through
a
number
of
revisions,
it's
about
a
year
old
now,
and
it
was
recently
taken
to
the
decentralized
identity,
foundations,
ID
working
group
on
did
methods.
A
There
are
some
open
issues
and
it
looks
like
it's
probably
going
to
be
updated
in
two
important
ways.
One
is
it's
going
to
use.
Something
called
carry
carry
is
a
generalization
of
some
of
the
techniques
that
exist
in
peer
dids
and
so
by
using
carry,
we
will
make
it
so
that
it
did
could
be
appeared
and
it
could
also
be
cross-registered
on
blockchains
in
some
cool
ways.
A
That
will
be
a
nice
feature
and
possibly
the
thing
that
we
saw
where
there's
a
section
where
you
authorize
the
the
keys
to
do
certain
things
could
be
updated
with
some
work
on
something
called
si
lang.
The
our
si
si
si
Lang.
That's
just
been
proposed
at
hyper
ledger
ursa,
but
there
are
existing
implementations
today,
and
this
is
relatively
mature
work.
It's
not
fully
mature
work,
the
it's
relatively
mature,
I'm
hedging
myself
a
little
bit
here.
A
A
A
The
deltas
are
shared
with
a
gossip
type
protocol
and
if
any
of
you
are
familiar
with
CR
dt
technology,
that
may
be
a
relatively
unfamiliar
term
to
some
but
CRD
t's
stands
for
conflict-free
replicated
data
type
and
Ciardi
T's
are
what's
behind
the
ability
that
all
of
us
take
for
granted,
which
is
you
open.
A
Google,
Doc
and
you've
got
20
people
all
editing
the
same
dock
at
the
same
time,
and
you
never
have
a
merge
conflict.
A
It's
actually
a
pretty
good
trick.
I
mean
how
many
of
us
can
imagine
that
much
change
happening
in
source
code
in
a
github
repo
that
we
work
in
and
not
ever
having
a
merge
conflict.
It's
that's
a
pretty
good
trick,
but
it
turns
out
that
it,
if
you
think,
really
hard
about
the
way
you
design
your
data
structures,
you
can
actually
drive,
merge
conflicts
out,
and
so
the
Delta
that
we're
talking
about
here
on
this
slide
is
a
delta.
A
That's
been
deliberately
designed
to
not
have
these
merge
conflict
problems,
I'm
going
to
show
you
a
series
of
four
diagrams
I'll,
just
page
through
them
really
quick
here.
These
are
different
ways
that
peer
dudes
might
be
managed
and
the
synchronization
or
replication
between
them
might
be
controlled
and
for
people
who
didn't
come
to
this
talk
with
a
decentralized
identity
background,
but
rather
from
a
general
blockchain
background.
I
think
this
might
actually
be
a
part.
That's
kind
of
interesting
to
you,
the
circle
or
the
ovals
here
represent
what
I
call
a
sovereign
domain.
A
This
is
the
set
of
things
that
one
identity
controls
that
you
could
say
are
in
the
world
of
that
identity.
So,
in
the
case
of
Alice
here
on
the
Left,
we
have
a
phone,
that's
a
dot
one,
a
for
Alice,
so
it's
just
Alice's.
First
thing:
we
have
a
cloud
thing,
a
dot
two,
and
then
we
have
two
pieces
of
paper
that
represent
keys,
that
Alice
controls,
but
she
doesn't
control
them
with
technology.
She
just
printed
them
out
and
stuck
them
in
a
safe
somewhere.
A
Okay,
so
these
could
all
be
part
of
Alice's
world
and
when
Alice
says
to
Bob,
hey
I'd
like
to
give
you
my
peer
did
I
want
you
to
know
that
it's
me
you're,
dealing
with
and
I
want
you
to
have
confidence.
When
you
see
data
that
purports
to
come
from
me,
you
need
to
know
whether
it
really
is
me
she's,
gonna
tell
Bob
about
four
different
things
for
different
keys,
a
dot
18.2,
a
dot
3,
a
dot,
4,
okay
and
she's
gonna
say
all
four
of
these
represent
me.
A
Now
they
might
represent
me
more
or
less
like.
Some
of
them
might
have
a
lot
more,
a
four
to
represent
me
than
others,
but
they
all
represent
me
to
some
degree
they're
all
inside
my
oval.
Okay,
meanwhile,
bob
has
a
similar
kind
of
a
world
there.
Maybe
he
has
some
variation,
he
might
have
a
tablet
or
something,
and
so
when
let's
say
that,
Alice
lose
it
well.
A
A
Who
does
he
say
that
to
and
that's
what
all
the
lines
and
arrows
around
here
are
answering
okay,
because
it
would
be
really
simple
to
believe
in
this
world,
namely
Alice
has
a
service
up
in
the
cloud
and
Bob
has
a
service
up
in
the
cloud,
and
the
service
always
knows
everything
about
Alice's
world
and
everything
about
Bob's
world
and
it's
always
up-to-date,
and
so
all
that
Bob
needs
to
do
when
he
loses
his
phone
in
the
couch.
Cushions
is
tell
his
service
in
the
cloud.
A
A
A
So
whatever
we
do
with
our
synchronization
protocol
has
to
handle
that
kind
of
a
case.
All
right,
I'm
not
going
to
spend
too
much
more
time
on
this,
because
I
think
we
could
get
bogged
down
in
the
details.
But
suffice
it
to
say
that
the
synchronization
protocol
that
Alice
and
Bob
run
to
do
dynamic
peer
dids
accounts
for
all
of
these,
and
it
does
it
without
being
overly
heavy.
A
But,
oh
by
the
way,
this
is
the
this
is
the
nastiest
one.
Imagine
that
you
have
a
company
Acme,
that's
corresponding
with
some
other
entity.
That's
a
swarm
of
bots
and
you're,
trying
to
use
the
same
kind
of
technology
and
look
at
some
of
the
arrows
here.
You
know
the
company
and
the
bot
swarm
might
have
a
direct
connection,
maybe
they're
both
based
in
the
cloud,
but
maybe
there's
a
server
at
Acme.
That's
talking
directly
to
a
particular
bot.
That's
a
sub
controller
over
a
subset
of
the
swarm.
A
A
This
is
where
I
wanted
to
get
to
so
in
that
in
those
messy
worlds
you
have
to
do
one
of
three
things
to
tolerate
the
messiness
thing
one
is
you
run
some
kind
of
a
consensus
algorithm
like
what's
the
consensus
about
Alice's
State?
That
could
be
a
way
you
could
approach
it
thing
to.
Is
you
could
centralize
that's
the
simple
picture
right
where
Alice
just
simply
tells
her
cloud
world?
A
Okay,
this
is
the
way
it
is,
and
that's
the
end
of
this
story
thing
three
is
forks
now
I'm
not
talking
about
Forks
like
let's
all
a
fork,
the
network
and
go.
You
know
play
in
our
own
world
like
angry
community
Forks,
but
I'm
talking
about
Forks
of
reality,
it's
possible
that
there
could
be
two
correct
answers
to
the
question:
what
is
Alice's
state?
A
How
could
that
be
true?
Well,
let's
say
Alice
who
left
was?
Was
it
Bob?
It
was
Bob
who
lost
his
his
phone
in
the
couch
cushions
Bob,
while
his
phone
is
in
the
couch
cushions
has
a
tablet
that
knows
that
the
phone
no
longer
has
a
valid
key
right.
His
tablet
has
found
that
out,
let's
say
and
maybe
Bob's
cloud
has
found
that
out
and
maybe
half
of
Alice's
world
has
found
that
out
too,
but
maybe
there's
a
network
brownout
or
some
other
reason
why
some
part
of
Alice's
world
doesn't
know
about
it.
A
Okay,
but
what's
interesting
is
some
part
of
Bob's
world
doesn't
know
about
it,
namely
the
phone.
That's
powered
off
in
the
couch
cushions
doesn't
know.
So,
let's
just
suppose,
I
know
this
is
crazy,
but
all
of
this
part
of
Bob's
world
that
did
know
about
the
change
is
now
inaccessible.
You
know
the
internet
went
down
powers
out
whatever,
but
but
Bob
found
his
phone
whoo.
Thank
goodness
now
he
turns
on
his
phone.
His
phone
wants
to
talk
to
Alice.
A
Well,
what's
gonna
happen
that
phone
is
not
an
invalid
phone,
it's
not
a
hacked
phone.
It
has
a
view
of
reality
that
was
authorized
by
Alice
from
its
perspective,
it's
real.
The
only
problem
is
it's
not
the
only
reality.
That's
a
that's
what
I
mean
by
a
fork?
Okay,
and
so
you
can
later
resolve
the
forks.
That's
what
the
synchronization
protocol
has
to
do,
but
you
can't
prevent
them
from
happening.
A
I
think
I,
think
we're
gonna
just
skip
over
the
rest
of
this
I'll
just
end
here.
If
you're
interested
in
this
topic,
I
find
it
from
a
computer
science
perspective
to
be
really
interesting
and
I.
Think
the
possibilities
for
using
these
dudes
to
identify
things
in
a
decentralized
way
are
really
compelling
and
I'm
giving
a
talk
in
an
hour
or
so
on,
patterns
of
decentralization.
A
These
are
like
gang
of
four
type
patterns
that
show
up
in
a
lot
of
decentralized,
architectures
and
I,
find
that
peer
dudes
actually
exhibit
some
very
interesting
properties
with
respect
to
decentralized
architecture.
But
anyway,
if
you're
interested
in
more
about
this
topic,
these
are
the
places
that
I'd
suggest
you
go.
The
top
one
is
the
official
spec
the
next
one.
Is
that
97
lines
of
code
that
you
could
probably
port
or
you
could
use
the
next
one
is
where
you'd
go.
A
If
you
want
to
go,
read
github
issues
and
see
what's
going
on
on
the
spec.
The
next
one
is
an
implementation
of
peer
dudes
in
Python
and
that's
available
on
pi
PI
as
well.
If
you
want
to
just
go,
get
peer
did
is
the
name
of
it
on
pi,
PI
and
I.
Don't
know
what
the
name
of
the
implementation
is
of
peer
dudes
in
go,
but
there
is
one
and
I
can
help
find
it
if
you're
interested
in
that
and
then
lastly,
there's
a
link
to
a
an
email
group.
A
A
A
You
can
prove
that
you
possess
the
did.
So
it's
not
like
it's
just
trusting
whatever
it's
actually
a
very
strong
form
of
trust,
but
what
you
would
have
to
do
is
you.
The
website
would
have
to
know
that
that
particular
did
is
one
that
it
likes.
So
you
establish
a
relationship
with
a
website.
You
trade
ins
once
you've
traded
those
dudes.
The
website
now
has
a
list
of
all
of
the
dids
that
it
likes.
A
Then
it
uses
OID
C
to
challenge
somebody
and
say
prove
that
you
own
a
did
I
like
and
the
person
proves
it
and
away
you
go
and
there's
been
demos
of
this
that
have
been
done,
that
are
very
slick.
Go
to
the
website
scan
a
QR
code.
You're
in
there
was
no
make
a
claim
about
who
you
are.
There
was
no
login
button,
nothing,
it
was
just
literally.
The
website
was
displaying
a
QR
code.
You
walked
over
there
and
scanned
it,
and
the
next
thing
happened.
Is
the
website
changed
and
said,
hi
welcome.
A
So
that's
one
way
to
do
it.
You
can
also
do
it
very
simply
by
basically
using
a
different
protocol.
Instead
of
using
the
SiO
P
over
o
IDC
stuff,
you
could
just
use
whatever
protocol
custom
protocol.
You
want
you
just
do
a
challenge.
You
say
prove
that
you
own
this
did
or
any
did
and
back
comes
the
thing
and
there's
that
subject
is
called
did
authorization
and
there
is
a
group
at
the
decentralized
identity
foundation,
a
working
group
that
knows
all
about
that
and
you
can
go
talk
to
them.
If
you
want
further
information.
A
So,
for
example,
you
could
ground
a
did
method
in
the
IP
FS
infrastructure,
instead
of
grounding
it
in
web
infrastructure,
and
if
you
did
that,
then
you
would
get
certain
properties
that
ipfs
provides
for
you
and
they
would
kind
of
come
along
with
your
did,
and
so
there
are
people
that
feel
like
hey.
I
want
to
have
a
did:
that's
grounded
in
Bitcoin,
because
I
live
in
the
Bitcoin
world
and
it's
a
great
way
to
you
know:
payment
addresses
of
things
that
I
like
I
eat
and
breathe
them
every
day.
A
So
that's
the
that's
the
basis,
so
there
is
a
basically
my
answer
is
yeah.
There's
a
did
method
for
that,
like
there's
a
did
method
for
the
DUI
world,
there's
a
did
method
for
the
Bitcoin
world
and
so
forth
and
and
dudes
were
deliberately
designed
to
kind
of
be
inclusive.
That
way,
I
think
we're
about
out
of
time.
I
could
maybe
take
one
more
question:
okay,
we'll
call
it
good,
then
thank
you.