►
A
A
A
A
A
A
A
This
protocol
reliably
communicates
data
about
pure
day
ideas
and
pure
did
docs
pure
fantastic
peers
must
persist
that
data
into
local
cache
or
database
that
functions
as
a
decentralized
identifier
registry.
For
the
method,
this
method
is
worthy
of
trust
because
it
guarantees
the
following
properties:
the
ids
are
associated
with
exactly
one
inception
key
at
moment
of
creation.
This
prevents
a
category
of
man
in
the
middle
attacks
where
attacker
could
rotate
a
did
keys
at
the
outset
of
the
relationship
unbeknownst
to
the
peers.
A
A
A
A
A
A
It
also
makes
it
possible
for
blockchains
to
graft
a
pdid
by
mapping
it
into
their
namespace.
Without
incurring
the
risk
of
ambiguity
anytime,
it
appears
discovered
to
be
less
than
unique
a
true
problem.
Existence
systems
can
fairly
raise
an
exception.
Values
of
dids
are
securely
random.
Okay,
this
prevents
attackers
from
discovering
patterns
and
dids
that
might
undermine
privacy.
Parties
to
a
relationship
can
prove
the
orderly
and
authorized
evolution
of
their
keys
to
one
another
in
an
unbroken
chain
of
custody.
A
A
Is
it
boiling
hot?
Okay,
thanks
baby,
I
love
you
okay,
so
this
is
perfect
in
centralized
system
security
is
enforced
at
the
center,
so
it
is
so
obvious.
We
take
it
for
granted.
You
can't
access
the
database
unless
you
log
into
it.
First,
it's
a
database
that
enforces
this
despite
other
decentralized
features.
Blockchains
are
no
different
in
this
respect.
If
a
blockchain
accepts
updates
to
a
did
doc,
then
the
blockchain
must
guarantee
that
those
updates
are
only
made
by
authorized
parties.
A
So
this
is
this
is
to
combat
people
putting
stuff
on
the
blockchain
that
you
don't
want
them
to
be.
Putting
on
the
blockchain
like
in
your
name,
is
my
understanding.
So,
basically,
if
you
want
to
say
hey,
this
is
related
to
that.
You
need
to
get
permission
effectively
by
getting
the
the
thing
you're
saying
something
is
related
to
and
having
it
sign
it
and
say:
yes,
okay,
yes,
I
I
agree
to
be
related.
A
A
This
process,
we
call
graph.
We
call
this
process
graphed
and
graph
when
crafting,
might
be
useful.
When
appeared,
id
needs
to
be
accepted
as
the
submitter
or
target
of
a
transaction
on
a
blockchain
when
a
blockchain
is
used
as
a
diff
dead
drop
for
a
pure
deity.
It's
important
to
use
existing
did
tools
that
consume
a
global
source
of
truth,
aeg,
the
dis
universal
resolver,
in
other
circumstances,
where
pd
peer
dd,
is
some
form
of
partially
public
reference.
So
this
is
exactly
what
we're
getting
at.
This
is
exactly
what
we're
looking
for.
A
So
grafting
can
be
done
in
several
ways
by
combining
another
did's
method:
prefix
with
appeared,
dids,
encoded,
nsi,
okay,
so
we
swapped
out
the
namespace.
Here,
I
think-
or
maybe
that's
not-
maybe
that's
the
name:
okay
by
creating
a
child
name
space
for
the
peers
beneath
the
other
method.
Okay
versus
no
xyz
by
re-encoding.
The
numeric
basis
of
the
the
pure
did
we'll
make
this
bigger
basis
of
the.
So,
let's
check
out
the
numeric
basis
of
the
prdid
using
rules
of
another
method.
A
Here:
xyz
method,
encodes
base64,
but
encodes
a
numeric
basis,
differently,
pros
and
cons
to
each
approach.
If
a
pdid
is
registered
and
graphed
into
another
did
namespace
using
any
graphing
method.
The
result
is
two
d
ids
with
different.
If
a
pdid
is
registered
and
grafted
into
another
did
namespace
using
any
grafting
method.
The
result
is
two
dids
with
different
namespace
one
pure
and
one
anchors.
Each
with
its
own
did
dock
a
decision
must
be
made
about
which
the
id
is
normative
for
the
relationship
or
whether
both
should
continue
to
be
used.
A
If
both
will
be
used,
it
should
be
understood
that
2d
ids
hold
keys
and
other
data
for
two
different
dids,
regardless
of
the
shared
history
of
those
dids.
Ideally,
there
would
be
no
difference
between
the
did
talks
stored
in
each
place,
but
even
with
the
best
intentions
of
the
did,
controller
differences
may
arise.
A
Basically
so,
and
this
is
why
the
manifest
this
is
why
the
manifest
the
manifest
section
of
the
documentation
on
building
manifest
talks
about
requirements
or
no,
the
shim.
It's
the
shim
yeah
the
ship.
They
both
talk
about
requirements
around
externally
data,
that's
external,
to
the
manifest
that's
being
referenced,
and
so
the
reason
for
that
is
you
know,
because,
even
if
you
think
it
won't
change,
because
the
url
is
static
like
what.
A
That
are,
you
know
different
than
what
we're
expecting,
because
this
this
room,
you
remember
all
these
peers
and
all
these
dids
are
basically
like
our
giant
linked
list,
and
so
our
our
the
content,
the
value
held
within
the
linked
list
is,
is
not
held
in
the
linked
list.
It's
a
pointer
basically
and
the
pointer
is
the
manifest.
A
A
A
A
A
A
Okay,
no,
I
don't
want
to
join
linkedin
on
this
computer.
Okay,
do
I
do
docs,
okay,
so
core
characteristics
introduction?
So,
oh
yeah,
we
skipped
right
to
the
security
concerns,
always
skip
right
to
the
security
concerns
that
way.
You
know
immediately
whether
this
fits
your
model
or
not,
because
you
don't
want
to
get
too
far
invested
in
something
and
then
start
bending
over
backwards
for
insecure
default
behavior
within
your
use
case.
A
Like
a
blockchain,
a
database
or
distributed
file
system
or
similarly,
the
publicness
lets
arbitrary
parties
resolve
the
ids
to
an
endpoint
and
keys.
It
is
an
important
feature
for
many
use
cases.
However,
the
vast
majority
of
relationships
between
people,
organization
and
things
have
simpler
requirements
when
alice
corporation
or
device
and
bob
want
to
interact.
There
are
exactly
two
parties
in
the
world
who
should
care
alice
and
bob
instead
of
arbitrary
parties
needing
to
resolve
their
dids.
Only
alice
and
bob
do
peer
d.
Ids
are
perfect
in
these
cases.
A
A
Okay,
so
this
is
this
is
exactly,
and
this
is
exactly
what
we're
talking
about.
Is
that
there's
just
not
a
lot
of
good
ways
to
get
data
on
and
off
the
blockchain
right?
And
so
this
is
how
we're
gonna
do
it?
Okay,
all
right.
They
move
the
bulk
of
interactions
off
chains,
but
offer
options
to
connect
back
to
chain
based
ecosystems
as
needed
exactly
right.
So
this
is
how
we're
going
to
bridge
our
web
2
to
our
web
3..
A
So,
basically,
so
we're
going
to
put
a
bunch
of
data
on
the
blockchain
right.
That's
the
data
we're
going
to
put
on
there
what
what
these
are
the
these
are
the
pd
ids
and
then
what
are
they
going
to
do?
Well,
they're,
going
to
reference
data,
that's
external
via
the
manifest
and
the
manifest
we're
going
to
encode
to
some.
You
know
to
to
we're
going
to
encode
it
in
some
in
some
some
scheme,
that'll
allow
us
to
put
it
within
a
did
dock.
A
I
believe
pure
deities
create
conditions
for
people,
so
it
looks
like
some
formal
terminology
may
make
the
application
of
in
this
insight
to
dids
cleaner
anyways.
The
idea
did
intended
to
use
for
with
use
for
an
unknowable
number
of
parties,
a
global
plus
public
asset
or
some
subset
they're
there
of
a
di,
so
pairwise
did
a
did
intended
to
be
known
by
its
subject
and
exactly
one
other
party,
a
g
e
dot
g
dot,
one
usable
in
the
allison
bob
example.
Just
above
ny
is
the
idea.
A
The
idea
intended
to
be
known
by
exactly
n
enumerated
parties,
including
its
subject,
a
business
partnership
with
three
members
might
be
modeled
with
nysd
ids
pairwise
are
just
a
special
case
of
ny's
dnds,
where
n
equals
two
more
on
nydid
see
groups
in
the
appendices,
generally,
okay,
so
important.
So
this
is
what
we
talked
about
yesterday
when
we
said
what-
and
this
is
what
stopped.
A
I
guess
the
way
that
I
had
been
doing
it.
You
needed
the
the
sender
to
re-encode,
but
you
could
have
sort
of
somebody
else
within
this
group
chat.
Anybody
who
had
been
in
there,
who
has
the
data,
could
just
sort
of
re-encode
it
for
you
and
I've
been
wondering
what
can
we
do
about
this
with
like
torrents
and
could
we
could
we
use
like?
Is
there
a
space
for
the
for
torrents?
Here
I
don't
know,
I'm
not
quite
sure
I
think,
there's
some
kind
of
intersection
that
we're
going
to
have.
A
A
A
That's
a
good
thing,
that's
a
very
good
thing
for
us
here
in
terms
of
getting
more
data,
that's
off
chain,
so
we
could
potentially
leverage
the
like
torrenting
and
web
torrents
for
the
initial
stage
of
getting
data
that's
off
chain,
because
that
already
implies
that
there's
some
distributed
network
built
up
on
that.
So
we
can
kind
of
take
that,
as
our
default
base
case
is
that
we're
going
to
basically
assume
web
torrent.
A
So
we
need
our
did
distribution
channel
so
basically
we're
gonna.
The
the
point
is
that
we're
gonna
take
these
dids
and
we're
going
to
put
them
in
arbitrary
sources
right
so
you're
just
going
to
put
these
things
random
places
and
then
using
the
sources,
api
right
and
the
data
flow
pre-processing
apis.
A
All
of
a
sudden,
you
can
start
grabbing
all
these
data
from
different
data
sources
very
easily,
because
you
know
they're
all
being
filtered
through
this.
As
the
the
incoming
the
incoming
source
is
basically,
you
know,
build
rebuild
my
data
from
the
did
chain
right
and
then,
if
you
write
your
proxies
to
your
web
to
space
as
encodings
to
the
ids
and
you
know
handling
with
the
granularity
of
the
permissions
thereof,
all
of
a
sudden
you
now
have
you
now
have
your
bridges
right,
and
so
your
bridges
only
need
to
focus
on.
A
Actually
all
your
new
bridges
really
need
to
do
is
focus
on
getting
the
data
out
and
in
of
the
web
2
space
that
you
want
and
then
so.
We'll
just
write
operations
for
that
right.
So
we'll
just
write
little
operations
that
just
take
data
out
data
in
a
web
web
to
stuff
right
and
then
we
will
and
then
we
will
so
data
out
data
and
of
web
2
stuff
right
and
then
you
just
we
just
have
another
set
of
operations.
A
Effectively
so
this
means
you
can
communicate
over
any
channel
and
you
can
have
as
much
out-of-band
communication
as
you.
Basically
you
you
can
build
it's.
It's
just
apply
you're,
applying
the
source
construct,
but
you're
and
and
really
when,
when
I
say
you're
applying
the
sources
construct.
That
just
means
that
you're
going
to
aggregate
all
of
the
the
the
the
different
data
sources
that
you
have
in
it
and
and
present
it
as
if
it's
one
right.
And
so
how
are
you
going
to
do
that?
A
A
A
A
Okay,
so
this
is
what
we're
talking
about
here.
Basically,
so
you
can
think
of
the
did
as
being
this
object
here
right.
So
this
is
what
am
I
dealing
with?
What
what
is
this
thing?
Okay,
so
I've
got
a
piece
of
data
right.
It's
a
model
lives
in
the
model,
namespace.
What's
the
what's
the
unique
identifier
within
the
model
or
what's
the
unique
identifier
within
the
model?
Namespace,
okay?
A
Well,
it's
going
to
be
something
generated,
cryptographically,
you
know,
for
this
specific
did
and
then
it's
going
to
you
know
encode
in
the
data
in
the
docs
section
at
least
we
haven't
read
that
it's
part
of
the
spec
yet
but
we're
assuming
that
it's
going
to
encode
in
the
docs
section
this
stuff
here
right
and
so
we're
going
to
say
you
know
what
kind
of
thing-
and
this
is
like
kind
of
our
manifest
right.
So
this
is
this
is
and
and
obviously
we're
going
to
flush
this
out.
A
A
A
A
Okay,
so
we
have
some
security
considerations.
Well,
what
am
I
thinking
right
now,
so
I'm
thinking
that
people
put
too
much
stuff
on
the
chain
because,
as
soon
as
I
said,
cbor
all
of
a
sudden,
I
saw
myself
putting
a
zip
file
on
there
and
I
thought
well,
you
know
not.
Everybody
may
like
that.
Not
everybody
may
not
like
propagating
giant
zip
files
through
right,
so
you
know
relay
size.
A
A
A
A
A
What's
the
last
created,
you
know
local,
because
you
can
say
what's
the
definition.
Like
so
say,
you
want
to
go
receive
something
from
from
the
network
and
you're
gonna
you're
gonna
write
it
out
to
disk
right,
and
this
is
any
and
and
so
the
reason
why
we
care
about
this
is
because
you
can
write
this
in
so
recently.
I
saw
something
that
was
somebody
somebody,
somebody
came
around
and
told
me.
A
You
know
I
would
like
to
you
know:
keep
the
size
of
the
files
written
to
some
small
amount
so
that
I
don't
fill
up
the
disk
and
I
went
and
I
took
a
look
at
it
and
I
noticed
that
we
were.
We
were
just
making
more
files.
So,
that's
not
really,
you
know
helpful
right
so,
but
we
we
need
to
you
know
we
we're
just
going
to
end
up
making
another
file
and
that
file
is
going
to
fill
up
the
disk
right.
A
So
we
need
to
have
some
some
some
first
of
all.
First
of
all,
it's
all
well
and
good.
If,
like
one
program,
does
that,
but
then
what's
the
command
line
flag
like
did
the
caller
remember
to
use
it,
you
know,
maybe
maybe
not
is
the
caller
consistent.
Can
I
change
it
if
I
have
a
different
environment?
What
if
my
environment
is?
Actually
you
know
more
resource
constrained,
and
you
know
20
gigabytes
is
not.
A
You
know
the
upper
bound
right
of
of
your
your
your
your
your
disk
space
here
right,
because
these
are
things
that
are
config
right
in
config.
Config
is
something
that
that
trickles
down
you
know
all
the
way
to
the
lowest
levels
it
really
needs
to
in
some
instances
and
and
and
the
the
the
the
important
thing
about
using
the
data
flows.
A
Give
it
g
and
give
it
this
value.
You
know,
give
it
this
value
and
what's
the
value
well,
the
value
is
dependent
right.
Maybe
it's
an
output
of
an
operation
that
was
calculate
disk
size
right
and
then
it
went
and
created
a
little.
You
know
spool
directory
similar
to
like
a
telemetry
situation.
You
know
so
you
know
where
you
may
only
have
wanna
have
so
much
information
sitting
around
in
a
little
directory
getting
sucked
up
by
telemetry
right,
so
you
may
create
a
partition
of
a
fixed
size
right.
A
So
this
is
the
type
of
stuff
that
would
be
done
on
startup
it's
device
dependent
and
then
needs
to
be
trickled
down
into
the
rest
of
the
settings,
so
that
sort
of
everything
can
cooperate
right,
because
if
you,
if
you
don't,
you
know,
if
you
leave
that
setting
at
20
gigabytes-
and
you
have
this
100
megabyte
spool
partition
for
your
telemetry,
you
know
all
of
a
sudden
one.
Bad
thing
comes
in
and
your
toast
right.
A
So
if
you
set
that
down
to
you
know
a
megabyte,
then
you
can
have
100
bad
things
come
in
then
your
toast
right.
So
so
that
gives
you
some
time
to
react
if,
if
you're,
if
you're
in
this
case,
alice
and
you're,
you
know
dynamically
interacting
with
your
environment,
right
and
you're,
detecting
these
nominal
anomalies
and
we're
going
to
have
the
ability
to
detect
those
anomalies
as
well
so
okay.
A
A
We
want
to
start
putting
something
on
the
blockchain
and
and
what
we
ran
into
last
night
was
what
are
all
the
arguments
we
need
to
pass
to
this
thing,
but
we
were
using
did
com
so,
but
it
looks
like-
and
I
didn't
quite
understand
that
thing
I
was
a
little
bit
tired,
but
I
didn't
understand
what
the
hell
we
were
looking
at
here,
so
handling
trust
on
first
use.
Okay,
so,
let's
see
actually,
let's
read
the
rest
of
this.
I
think
we're
in
the
security
considerations.
Gotta
love
the
security
considerations
yeah.
A
A
That,
if
you
keep
these
in
mind,
then
you
can
effectively
mitigate
for
for
these
right.
So
as
long
as
we
keep
this
in
mind
right,
which
is
once
again
why
we
talked
about,
you
know
how
we're
going
to
make
how
we're
going
to
make
a
machine
read
these
specs
right,
which
are
very
human
language
focused,
and
you
know
what
would
like
how?
How
would
they
know
what
to
do
with
that
right
and
why
do
we
care
about
having
them
read
the
spec,
because
we
would
really
really
really
like
to
just
go.
A
Tell
the
computer
to
write
some
code
and
then
not
have
to
write
any
code.
I
mean
I
writing
code
is
great,
but
it
would
be
better
to
not
write
any.
I
think
I
think,
would
be
better
if
the
machine
wrote
all
the
code.
So
as
long
as
we
can,
you
know
provide
certain
guarantees
around
that
right,
free
room
and
privacy.
Preserving,
let's
see,
I
think
it
may
be
the
only
path
to
an
early
retirement.
A
So
in
centralized
systems
security
is
force
at
the
center.
It's
so
obvious.
We
take
it
for
granted.
You
can't
access
the
database
unless
you
log
in
first
okay.
So
basically,
despite
their
other
decentralized
features,
blockchains
are
no
different.
In
this
perspective,
if
blockchain
accepts
updates
to
a
did
jock
dock,
the
blockchain
must
guarantee
that
those
updates
are
only
made
by
authorized
parties,
blah
blah
blah.
Okay.
We
already
talked
about
this.
That's
most
did
methods.
Imagine
a
blockchain
parsing
the
authority.
A
Excuse
me
so
then,
okay,
look!
This
is
critical.
So
then
the
blockchain
must
guarantee
that
those
updates
are
only
made
by
an
authorized
parties.
Thus
most
did
methods.
Imagine
a
blockchain
parsing,
the
authentication
section
of
a
did
doc
and
rejecting
mischief
from
hackers.
So
what's
that
that's
what
we
just
wrote,
that's
what
we
said.
Basically
we're
gonna
we're
gonna
we're
gonna
we're
gonna
go
with
like
what
look
look.
I
mean
so
okay.
A
So
basically,
this
is
saying
you
know,
so
we
can
implement
okay,
we're
implementing
anything
that
holds
these
dids
effectively
becomes
a
blockchain
right.
So
basically,
what
we're
saying
is
you
can
take
the
existing
sources
that
exist
right?
That
we
have-
and
you
can
basically
make
anything,
a
blockchain
and
anything
a
bridge
right,
so
this
is
gonna,
make
data
analysis
and
import
export
trivial,
so
very
excited.
A
A
A
You
know
we
can
even
add
more
levels
of
indirection
within
trusted
environments,
depending
on
our
the
scope
and
and
and
the
way
that
we
threat
model
those
environments
right.
So,
for
example,
we
can
use
within
our
our
chat
that
we
have
right.
Maybe
we
have
you
know
an
authorized
list
of
maintainers
and
those
maintainers
using
certain
keywords,
reference
certain
assets
right-
and
we
have
this
this,
this
indirection,
or
maybe
even
not
even
the
maintainers,
but
anybody
within
the
channel
right.
A
A
A
A
A
A
Okay,
so
basically
what
have
we
said
here?
So
we
said
we
have
these
little
proxies,
so
basically
our
so
we
have
the
proxy
to
the
web,
to
web3
environment.
So
what
and-
and
how
are
we
so
so?
The
last
thing
that
just
happened
here
was
important
because
we
just
tied
together.
So
this
is
I'm
I'm
yay,
so
we
just
tied
together.
This
was
another
piece
that
was
missing,
so
we
tied
we
were
able
to
tie
the
to
effectively.
A
I
think
I
think
we
haven't
gone
and
done
it
yet,
but
but
the
dataflow
is
class
seems
like
an
effective
method
for
exposing
data
flows
via
a
more
user-friendly
api
and
also
allowing
us
to
implement
our
you
know.
Our
own
classes
within
you
know
just
as
single
functions
and
really
you
know,
get
the
maximum
amount
of
reuse
right.
The
the
the
smallest
unit
of
reuse
is
is
a
function
right
or
a
routine
an
operation.
A
So
so
we
were
able
to
get.
You
know
our
unit
of
is
back
down
to
that
granular
level
of
a
function
if
we
can
define
things
as
operations
and
then,
if
we
can
implement
our
interfaces
via
the
data
flow
as
class,
then
we
can
basically
knit
together
all
of
these
different
functions
and
use
them
across
classes,
implementations
of
classes,
but
we
can
share
specific
data
as
we
want,
depending
on
the
locality,
and
we
can.
That
also
enables
us
to
to
synthesize
to
a
particular
you
know
given
given
any
particular
synthesis
mechanism.
A
It
understands
where
your
boundaries
are
for
locality
and
for
trust.
I
think
we
had
some
stuff
ooh,
I'm
remembering
some
stuff
about
the
origin
yeah.
So
all
of
this
all
of
this
stuff
tells
us
you
know
what
kind
of
input
validation
do
we
apply.
Where
do
we
apply
it
based
on
the
locality
and
the
trust
boundaries?
A
A
So
what
did
we
just
say
here?
So
we're
basically
saying
you
know
we're
going
to
create
this
bridge
from
the
web
2
to
the
web
3
space
and
how
we're
going
to
do
that?
Well,
we're
just
going
to
do
it
the
way
we're
going
to
do
everything
else,
which
is
we're
just
going
to
write,
little
functions,
little
operations
right
and
so
then,
so,
basically
we're
writing
all
our
we're.
Writing
our
little
data
collectors
right.
So
we
went
and
got
the
ice
cream
data
right
and
now
we're
reporting
out.
A
You
know
what
is
the
you
know
what
what
what's
what's
this?
What's
this
we
ran,
we
ran
the
operation
to
do
the
ice
cream
data
right
and
it
looked
up
the
the
temperature
in
the
the
city
or
something
right
in
a
particular
month,
and
so
when
we
return
that
output,
the
okay.
So
let's
update
this
so
we're
going
to
pop
a
shell
here.
A
Damn
I
had
a
contact
switch
and
I
lost
my
train
of
thought:
okay,
encode
the
dod
store
and
source
by
adding
method
to
error
defined
via
data
flows
class
within
okay.
Let's
finish
this
comment,
I
think
we
were
going
to
go,
show
something,
but
we're
going
to
show.
I
can
look
at
the
playback.
I
guess
input
network
made
from
dataflows
class,
for
example
on
add
input,
network
encode
to
did
store
and
source
by
calling
matt
method
of
input
network
defined
via
data
cloud
in
this
class
within.
A
A
Basically
we're
gonna
link
in
all
of
that
data
to
your
existing
systems,
right
so
that
you
can
feed
in
any
of
those
config
properties
dynamically
and
then
we're
going
to
step
deeper
than
that
and
we're
actually
saying
you
know:
why
do
it
just
for
the
containers?
But
let's
do
it
for
all
of
the
config
available
from
every
piece
of
code
running
within
that
container
right,
that's
what
we're
saying,
okay
and
then
I
think
I'm
going
to
take
a
break.