►
From YouTube: IPFS DDC WG - Identity - 20190122
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
here
here
we
are
again
and
hi
everyone,
so
we
are
here
to
discuss
a
few.
A
few
I
mean
just
one
topic
of
that
entity
which
is
wish,
or
the
first
yadi
method
that
will
embrace
is
very
important
and
we
need
to
come
up
with
with
a
decision
on
these
subjects,
because
we
will
not
be
able
to
embrace
two
or
three
guiding
methods
as
the
first
as
the
first
one,
because
it
will
require
more
work.
A
So
we
need
to
make
a
decision,
it's
very
important
for
us
to
feel
safe
in
terms
of
the
first
having
method
to
adopt
so
the
first.
The
first
thing
that
we
need
to
consider
is
that
we
have
three
candidates
and
I'm
already
going
to
the
agenda.
So
this
is
the
first
topic.
Imagine
and
in
terms
of
the
discussion,
which
is
decide.
The
first
element
we
have
IP
ie,
you
port
and
block
stack
so.
B
A
A
A
So,
in
terms
of
the
three
candidates
IP
ID
is
at
the
ID
method
based
on
IP
FS.
More
specifically,
it
uses
IP
ns
in
order
to
add
mutability.
So
essentially
you
have
your
D
ID
and
your
D
ID
I'm
gonna
write
here.
As
an
example,
you
know
the
ID
will
be
something
like
the
ID
ID
ID
and
your
and
your
the
hash
of
your
public
key
after
a
Kanis
entry
or
your
appeared.
A
So
this
is
this
is
based
on
IP
ID
specification,
which
is
was
created
by
Johnny
crunch,
and
it's
really
simple.
Basically,
you
point
user
pin
has
to
point
to
a
different
version
of
the
ID
documents
and
in
a
document
for
people
that
don't
know
already
I
can
head
here
an
example
short
example.
So
we
have
a
list
of
public.
Is
it's
not
really
like
that?
But
imagine
something
like
this.
A
If
he
is
communication,
for
instance,
I
can
say
that
this
one
and
this
one
can't
can
or
may
be
used
for
authentication.
So
essentially,
this
data
method
is
based
on
ffs,
an
openness
and
whenever
you
need
to
need
to
mature
to
the
document
you
create
the
document
put
it
on
that,
the
first
you
have
this
ID
and
then
you
say:
okay,
these
are
penis
entry
now
points
to
the
new
Sally.
That's
basically
it
they
show
with
this
approach
and
that's
one
of
the
points
of
the.
A
A
A
B
C
C
B
A
If,
if
we're
gonna
rock
stack,
we
need
to
understand
that
I
play
D.
I
uses
IP
NS
and
we
need
a
penis
to
be
stable
and
be
reliable
and
be
performance
and
by
talking
to
a
few
people
on
the
lipid
to
be,
and
also
the
FS
projects.
Some
concerns
were
raised
in
terms
of
those
topics
like
performance
instability.
So
we
invite
Fusco
to
this
discussion
it's
contributing
to
the
LEP
to
be
on
the
JavaScript
side.
So
if,
if
puzzle
vasco,
could
you
give
your
feedback
and
potential
solutions
to
to
the
performance
and
reliability?
D
Yeah,
okay,
can
you
hear
me?
Well,
yes,
okay,
so
small
update
in
the
current
state
of
IP
nests
in
the
next
release
options.
Ffs
there
is
the
0
to
35,
will
hopefully,
after
dick
cheney,
employed
by
default
and
also
interrupt,
probably
to
idea
fest,
which
essentially
is
necessary
for
you
to
use.
I
pianist,
however,
I
penis
is
still
not
performance
and
the
biggest
bottleneck
is
as
we
identified
in
the
lipid
to
be.
D
Teamwork
is
the
DHT
performance
both
in
go
ingest,
but
we
currently
do
not
have
benchmarks
about
how
much
time
we
take
that's
one
of
the
things
that
we
will
hopefully
do
in
a
near
future.
However,
now
the
most
efficient
way
of
using
Ibanez
in
JavaScript
and
the
Austin
goal
is
enabling
the
over
web
self
and
using
only
the
DHT
for
persistence,
which
may
be
a
way
for
you
to
start.
D
D
So
during
the
q2
during
this
quarter,
we
intend
to
have
a
plan
on
how
to
improve
the
DHT,
and
with
this
plan
we
tend
to
operate
it
during
q2,
but
we
don't
say,
eff
the
plan
yet
so
we
don't
exactly
know
how
long
it'll
take.
But
the
current
point
is
to
have
IP
NS,
/
DHT
and
more
performant
DHT
by
the
end
of
q2.
A
Let's
say
that,
let's
create
a
scenario:
let's
create
the
best
possible
scenario
right
now,
like
let's
say
that
I
have
a
good
connection
and
I'm
already
connected
to
a
lot
of
peers
and
I,
decide
to
make
a
change
to
my
opinion
century
to
point
to
another.
It's
something
else.
Do
you
have
some
kind
of
benchmarks
right
now
in
terms
of
the
current
state
of
the
implementation?
How
many
seconds
that
it
was
it
take
for
milliseconds?
Is
it
take
to
change?
Try
to
propagate
the
change.
D
D
A
D
But
as
I
are
experienced
with
the
openness
over
bed,
so,
but
so
that's
I
said
that's
the
best
way
for
you
to
start,
because
in
the
end
I've
been
a
thief.
Uni-Ball
I've
been
honest
over
pub.
So
basically
you
will
subscribe
to
the
topics
that
you
want
and
you
will
receive
in
real
time
the
the
updates.
So
you
are
subscribing
all
the
modifications
of
happiness
record,
the
first
time
it
will
take
a
lot
because
it
will
need
to
fetch
it
from
the
DHD,
but
afterwards
you
can
fetch
it.
D
A
C
On
the
I'm
not
sure
exactly
how
its
implemented
on
the
JavaScript
side,
we're
on
the
go
side,
something
Vasco
and
I
were
talking
about,
was
on
the
go
side.
They
have
streaming
implementation.
So
the
way
that
I
pns
works
is
it
basically
goes
and
tries
to
fetch
I
think
something
like
sixteen
different
copies
of
the
key
from
throughout
the
DHT,
which
is
why
it
takes
so
long.
C
D
That
will
be
our
first
approach
and
we
hopefully
will
have
that
in
for
you
for
q1
by
Jane
of
Q,
but
even
using
the
there
is,
for
instance,
the
that
guys
from
open
Bazaar
that
made
a
modification
of
Goering,
only
a
single
DHT
record,
which
is
way
faster,
but
also
has
problems
about
synchronization
and
if
we
end
up
providing
the
stream
API.
There
is
also
to
be
considered
that,
from
your
side,
you
will
need
you
will
need
to
decide
which
will
be
the
best
record.
There
is
the
most
recent
I
guess,
yeah.
C
A
I
would
say
that,
in
terms
of
the
trade-offs
between
security
and
performance,
we
are
more
inclined
to
the
security
side,
because
we
are
dealing
with
you
know
the
ID
isn't
getting
documents
that
must
be
in
the
sense
that
we
can't
really
lose
information
or
at
least
make
an
effort
to
not
lose
information.
So,
let's
consider
a
scenario
scenario
where
you
have
two
public
keys,
headed
to
your
D
ID
document.
A
If
one
one,
the
computer
or
device
updates
the
type
in
s
records,
but
pointing
to
a
D
ID
document
that
doesn't
have
the
full
previous
keys,
it
will
be
an
issue.
So
we
have
to
consider
that's
now,
and
perhaps
there
are
so
other
solutions
or
other
extra
steps
on
top
of
the
string
API
that
we
can
implement
in
order
to
make
it
more
secure
as
well
as
performance.
That's
why
we
are
here
to
discuss
Iran
that.
B
D
B
I
make
a
question
also
about
the
inner
workings
of
up
in
a
penis,
so
there
I
believed
the
the
the
record
has
Latinas
record.
Has
a
sequence
number
right
that
is
tend
to
be
is
monotonic.
It
increases
one
on
each
update,
but
that's
true
for
the
same
device.
If
you
up
do
have
the
same
key
on
two
different
devices,
the
same
happiness
on
two
different
devices
and
do
concurrent
polish,
you
will
end
up
with
a
dish
synchronization
right.
Yes,.
D
B
B
A
That
was
a
one
I'm
gonna
suggest,
if
it's
possible
to
think
about
and
so
on,
a
solution
that
I
will
solve
the
root
e
writer
scenario
of
including
concurrent
updates.
Much
like
the
the
things
we
are
dealing
with
with
charities
and
so
on
or
deck
deck
pointers.
It
will
solve
the
problem
that
we
are
having.
A
A
Do
you
have
any
idea
on
having
like
a
side
chain
for
this,
like
think
about,
think
about
type
ans
as
a
block
chain,
in
the
sense
that
it
is
the
source
of
the
truth,
but
is
slow
and
and
so
on?
Could
you
have
like
a
side,
suite
and
or
a
side
chain
that
we
could
more
be
more
real-time
in
terms
of
peptides
and
there
won't
be
any
conflicts?
And
then
we
polish
to
the
IP
NS
entry
and
the
the
result
of
the
merging
itself.
B
There's
me
some
back
and
forth
so
I
think
the
consensus
was
that
happiness
wasn't
design
itself
to
be
multi
device
or
multi
multi
peer,
and
so
yes,
any
any
solution
that
we
have
would
have
to
be
on
on.
On
top
of
that,
there
do
remember
those
those
conversations
on.
What's
the
status
of
the
multi
well,
I
know
you
weren't
there,
but
you've
been
doing
some.
We
have
that
fresher
in
in
your
mind,
perhaps
what's.
A
C
B
There
was
also
some
comfort,
yeah
I
guess
so
I
remember
a
bit
now
you
would
have
a
leader
and
one
of
the
two
peers
that
shares
that
ipsp
would
be
responsible
at
any
given
time
for
the
updating.
So
even
if
you
have
like
a
sidechain
per
device,
one
of
the
peers
would
be
an
either
explicitly
or
implicitly
be
like
the
leader
using
friendly,
for
instance,
leader,
election
or
implicit
leader
assignment
and
and
that
leader
would
be
responsible
for
updating
the
happiness.
Entry
with
the
official
version
do.
B
B
C
So
so
we
were
sort
of
thinking
about
it
in
the
context
of
persistence,
as
you
say,
and
so
we
kind
of
like
added
a
layer
on
top
which
was
to
have
leadership
election.
So
obviously,
if
you
have
a
single
leader,
then
that's
your
your
single
writer,
so
that
sort
of
adapts
itself
to
the
IP
n
s
scenario
with
a
single
writer
right.
C
But
then
you,
as
you
say,
Andre,
there's
a
problem
where,
if
you
get
this
split
brain
and
two
leaders
can
start
overwriting
each
other,
so
it
turns
out
it's
possible
to
detect
when
that's
happening,
and
so,
if
you
detect
one
of
them
backs
off
and
eventually
you'll
get
into
a
consistent
state.
So
that
I
think
was
eventually
where
we
landed.
A
All
right
so
just
to
further
and
give
importance
to
this
matter,
even
even
I
mean
this
problem
that
we
are
having
like
multi
right
of
scenario
is
not
only
strictly
associated
with,
like
ENS
and
sorry
to
IP
ad,
because
we
have
have
a
discussion
about
identity
profile
and
we've
if
we
opt
for
using
IP
FS
to
store
the
identity
profile
and
so
on.
We'll
also
have
these
kind
of
problems
like
I
I
in
multiple
devices
can
edit
my
profile
and
we'll
deal
with
multi
writer
scenarios
and
conflicts,
and
so
on.
A
So
it
will
make
probably
make
sense
to
solve
this
in
an
agnostic
way
and
in
some
moments
or
low-level
library
that
we
call
who
use
in
this
and
this
IP
ID
method
and
also
for
other
use
cases.
As
you
said,
on
your
side
on
pure
bass,
persistence
and
also
on
on
letting
people
file.
Does
it
make
sense?
Yes,.
B
The
view
of
the
strategy
as
the
GID
document
itself
to
the
to
the
upper
layer
I'm
wondering
whether
this
mechanism
is,
is
something
that
well
that
for
the
first
situation,
that
should
we
need
to
have
this,
making
this
multi
writer
multi
writer
capability.
Or
could
we
like
default
to
something
like
if
we
detect
them
by
will
detect
conflicts,
and
then
we
alert
the
user
or
something
because
the
user
will
be
the
same
user
right?
It
would
be
the
same
human,
correct,
correct,
yeah,.
A
B
Well,
you
could
always
store
as
charity
and
it
will
be
automatically
merge
of
all.
The
thing
is
that
we,
the
GID
document
itself,
will
not
unless
I'm
I'm
wrong
about
it.
The
LED
document
itself,
being
a
CR
DT
is
the
reality,
is
a
complex
data
structure
is
not
that
the
ID
documents,
so
it
does
not
conform
to
the
GID
spec.
And
if
you
started
sanity,
they
don't
unhappiness
for
later
conflict
resolution,
and
so
it
will
not
have
the
you
know.
B
A
At
least
what
the
spec
says
is
that
the
resolver
of
the
ID
method
must
return
the
value
added,
a
large
and
there's
actually
many
native
methods
that
use
a
more
kind
of
operational
strategy,
not
not
really
but
similar.
For
instance,
you
port
is
exploring
with
shipper
di
D
methods
based
on
ETA
as
well
that
they
use
in
the
sense
that
they
use
the
events
capability
of
smart
contracts
to
reconstruct
the
whole
Yeley
document.
A
So,
instead
of
storing
the
di
D
document
the
holy
document
in
each
operation,
you
just
store
the
question
itself,
like
I've
added
this
public
key
I've
removed
these
authentication
key
and
so
on,
and
then
what
they
do
is
they
read.
The
whole
events
are
fired
by
the
smart
contracts
and
reconstruct
the
ID
documents
based
on
those
events,
so
it
will
be
similar
to
that
sense.
Our
if
you
end
up
going
by
that
approach.
A
D
A
A
A
That's
point
tools
to
a
deck
node
that
has
the
last
operation
and
that
the
leg
node
itself
points
to
the
previous
operation
and
so
on,
and
then
what
we
basically
do
is
so
resolve
all
those
like
the
deck
nodes
based
on
their
partial
order
and
then
use
like
a
tiebreaker
or
something
like
that
to
break
the
tie.
So
you
end
up
with
a
shine
of
tagged
nodes
that
are
like
operations
and
you
in
the
end,
you,
you
have
the
ID
documents
based
on
those
operations.
Basically
does
it
make
sense?
It.
C
A
A
D
B
A
A
Well,
how
can
you
reliably
store
the
pointers
or
the
heads
of
the
diagonals
concurrently,
let
that's
a
different
problem,
so
let's
say
that
I
I'm
off
offline
or
partially
offline
and
in
another
device,
I'm
fully
online
and
I
make
a
change
like
I
approve
a
device
on
both
devices
and
other
device.
Both
will
point
to
a
new
head
and
we
must
write
to
that
to
the
IP
NS
injury
right.
How
can
we
deal
with
that
yeah
currently.
B
B
D
Basically,
you
the
entity
that
publishes
I
penis
record
it
also
so
it
besides,
sending
it
to
the
network.
It
stores
it
in
the
in
the
local
data
store
as
well,
and
basically
there
is
two
different
case
when
which
is
supposed
to
be
kept
locally
and
another
one
which
is
used
for
the
routing
in
in
order
to
understand
every
time
what
supposedly
it
was,
the
last
published
one,
but
only
so
if,
when
we
look
for
the
key
in
the
network,
the
the
key
will
be
different
from
the
local
one
and
the
Pires
hasn't
a
notion
of.
B
C
D
C
Well,
what
I'm
imagining
is
that
it
would,
it
would
imagine
any
new
changes
in
that
way.
You
could
keep
track
of
concurrent
heads
and
then
you
could
resolve
them.
So
the
problem
now
is
that
you
can't
you're
always
overwriting.
What's
there
instead
of
looking
at
what's
there
and
merging
something
into
it,
so
you
can
keep
track
of
concurrent
heads
that
make
sense.
D
I'm
I'm
not
sure
because
the
DHD
itself
does
not
have
idea
of
the
techies
that
are
used
in
the
IP
NS,
because
the
the
DHT
just
receives
foot
puts
and
gets
in
Myr
and
eventually
merges.
But
the
it's
received
previously
imagined
put
from
the
IP
NS
module
and
all
the
Ibanez
module
also
made.
It
puts
to
the
local
data
store,
which
is
like
in
a
different
place
from
the
DHT.
B
D
Basically,
when,
when
you
query
the
the
DHT,
it
gets
those
16
records
across
the
network
and
it
as
that
function
which
selects
which
one
of
the
16
records
are
the
best
is
the
best
one
and
from
there.
If
are
there,
if
they
are
different,
it's
okay,
this
one
is
the
best
I
will
broadcast.
Now
these
two,
the
remaining
beers
that
told
me
that
they
had
record,
but
it
is
outdated
and
all
of
them
updates
the
new
one.
All.
A
All
right,
so
that
basically
gives
us
some
guarantee,
in
the
sense
that,
if
the
new
peer
is
really
behind
and
tries
to
update
the
record
and
the
new
records,
there's
an
inner
attackers,
actually
that
new
record
will
be
published
instead
right.
So
so
after
the
operation,
the
the
peer
can
query
again
in
terms
of
fetching
the
record
and
if
it's
different
from
what
he
published.
It
means
that
he
was
out
of
date
and
and
his
operation
was
kind
of
denies
correct.
A
A
So
let's
say
that
the
first
year
is
very
cold
and
and
it's
very
behind
in
terms
of
the
the
the
whole
network
and
is
offline
right
now,
alright
and
the
nuclear,
the
new
pure,
the
second
pure
publishes
a
new
record,
and
after
some
time
I
like
that,
let's
say
one
month,
the
first
beer
gets
back
online
and
immediately
tries
to
publish
a
new
Hecker's.
Alright,
there's
the
new
record
goes
true,
or
does
it
get
denied,
because
the
second
peer
is
actually
published.
Something
before
that?
Isn't
that
the
first
we
didn't
know
about
it
goes
through.
A
A
A
C
E
C
A
All
right,
all
right,
so
basically
that
come
off
DS
was
that
vasco
hopes
to
have
see
if
he
can
improvements
on
the
performance
of
of
IP,
IE
and
I've
happy
sorry,
and
also
we
might.
We
need
to
come
up
with
a
solution
for
the
multi
writer
scenario.
There
are,
there
were
been
a
few
candidates
for
this
I
think
we
need
to.
You,
know,
think
of
you
think
of
it,
a
synchronously
and,
and
also
maybe
maybe
comment
on
the
under
issue.
Few
proposals
to
solve
this
because
we
need
to.
A
There
are
some
other
problems
that
we
need
to
tackle
on
this
discussion,
and
we
have
about
50
minutes
and
I
would
like
to
address
another
concern
that
I
have
so
we
have
another
problem
of
IP
ID,
which
is
basically
because
you're
the
ID
is
composed
by
the
hash
of
your
public
key.
It
means
that
if
your
private
key
is
compromised,
that
the
one
that
used
update
record
gets
compromised
somehow,
essentially
you're
the
IDS,
the
whole
identity
is
compromised
it
you
can
really
recover
it,
because
the
ID
itself
contains
the
private
key.
A
So
you
can
solve
the
public
key.
So
this
means
that
you
can
can
simply
issue
another
one,
because
the
rdid
will
be
different.
It
is
does
it
make
sense
to
anyone
so
that
we
are
in
the
same
page.
That's
all
right,
so
I've
been
think
about
a
few
solutions
to
this
problem,
and
we
have
the
first
solution
that
that
I've
listed
here.
A
It's
not
really
a
solution,
it's
more
like
something
that
we
force
to
two
users.
So
basically,
because
this
is
an
issue,
it
means
that
there
are
cleanest
private
key.
The
private
key
that
used
to
play
type
in
s
record
needs
to
be
kept
safe
and
away
from
the
devices.
So
it's
actually
on
the
first
time
that
user
ID
M,
we
construct
the
the
private
key,
and
this
is
another
question
Vasko.
Can
we
construct
a
penis
privately
ourselves
or
is
it
something
that
is
built-in
and
we
don't
really
have
an
option
to
create
it.
D
Yes,
basically,
if
you,
if
you
start
at
least
in
the
CLI
I,
think
the
HTTP,
it
should
be
the
same.
If
you
start
the
demon
with
new
key.
If,
for
instance,
you
use
the
ipfs
key
generate
and
generate
your
own
key
and
afterwards
you
start
the
demon
and
you
map,
like
that.
The
key
that
you
want
to
use
is
dead
key
instead
of
the
key
from
the
period
cell
right,
then
you
can
use
it
all.
A
Right
because
my
solution
was
to
use
Shamu
secret
Charlene,
so
basically
we
have
12
words
that
we
can
use
to
reconstruct
the
private
key.
So
basically
the
devices
wouldn't
have
the
the
die
penis
private
key,
almost,
never
and
and
once
it's
needed,
because
it's
least
needed
to
update
the
deity
documents.
We
ask
for
a
few
of
those
words
in
order
to
reconstruct
the
private
key
temporarily
issue,
an
update
on
the
DNA
found
on
the
records
on
the
penis
record
and
and
delete
it
afterwards.
So
it's
something
like
temporary.
A
Imagine
like
in
terms
of
the
user
interface
you
are
guided
to
throughout
the
creation
of
your
identity
and
in
the
final
step
it
will
be
something
like
okay,
you
have
to
store
these
words
in
order
to
recover
your
identity.
Please
make
sure
that
you,
you
have
those
words
written
somewhere
and
safely
stored
because
you
they
will
be
deleted
and
once
the
user
clicks
next,
it
will
be
prompted
again
to
confirm,
and
then
we
do
it.
So
this
is
basically
the
solution
number
one.
A
Yeah
exactly
so,
the
issue
is:
whenever
you
need
to
add
a
new
device
or
revoke
a
device,
you
need
to
prompt
for
the
the
the
percentage.
A
certain
percentage
of
those
twelve
words
we
see
is
not
very
easy.
Frank
Lloyd,
Wright
there's
something
to
consider
which
is
the
the
the
the
amount
of
times
that
you
adding
a
new
device
and
removal
device.
We
move
a
device
is
not
that
frequent,
but
I
still
not
use
a
friend,
so
I've
been
thinking
about
another
solution
and
the
solution
number
two,
which
is
a
layered
key
solution.
A
So
let
me
try
to
explain
and
and
bear
in
mind
that
it
might
take
some
time
to
throw
it
in
the
center,
but
I
will
try
to
explain
so.
Essentially
it's
similar
to
the
solution,
one
in
the
sense
that
we
have
a
private
key,
that
controls
the
records
records,
but
that
apenas
record
doesn't
point
to
the
heads
or
to
the
DA
development
itself.
A
It
points
to
another
IP
NS
record
right
and
that
that
second
record
is
controlled
by
a
layer,
2
IPS,
private
key
and
that's
second
openness
records
actually
points
to
the
heads
or
to
do
to
the
D
ID
document.
What
these
gives
has
is
that
we
can
have
the
second
layer
key
shared
among
devices
so
that
we
can
easily
add
a
new
device
to
that
that
list,
because
we
are
in
the
control
of
the
idea
of
unit
cells.
A
But
whenever
we
need
to
really
book
a
new
device,
we
need
to
basically
generate
a
new
layer
to
open
s
key
disseminated
to
to
all
the
devices
except
the
ones
that,
except
the
one
that
we
are
kicking
out
and
and
lastly,
we
applied
the
layer
1
P,
pointing
to
the
to
the
second
to
the
new
second
layer
to
key
so
in
terms
of
user
friendly.
It's
very
easy
to
add
new
devices.
A
Imagine
you
are
creating
a
new
device
or
say
that
setting
up
IDM
on
a
new
device
and
you
already
have
IDM
on
another
device
and
you
can
select
from
which
device
you
want
to
import
or
set
up,
and
you
click
on
that
device
and
we
need
to
scan
that
QR
code
and
the
second
layer
key
will
be
encrypted
and
passed
to
the
new
device.
So
it
will,
it
will
be
shared
among
devices
now.
Does
it
make
sense?
Because
it's
something
quite
complex.
A
All
right
so
in
the
key
points
is
that
is
more
secure
in
the
sense
that
you
don't
need.
You
need
the
delay
one
key.
There
often
you
just
need
when
we're
walking
device
and
we
still
have
and
it's
more
user
friendly,
because
you
can,
you
can
scan
care
codes,
you
can
always
ask
for
the
twelve
words
fall
from
the
lair
to
key
and
which
is,
you
know,
good
for
the
user
experience
when
Perry
in
your
device.
A
B
B
A
So
so
the
busy
the
the
thing
is
that
the
layer,
one
key,
is
not
stored
on
the
devices
it's
actually
stored
temporarily
until
you
back
it
back
it
up
like
imagine
in
IBM,
you
have
like
a
a
warning
sign:
hey.
You
need
to
backup
your
these
disturb
words
or
also
like
that.
When
was
it's
done,
then
the
like
one
key
is
completed.
A
You
just
start
by
you
or
you
can
even
disseminate
the
words
to
your
friend
and
so
on,
and
then
the
delay
to
key
is
actually
what
it's
stored
on
the
devices
in
order
to
easily
have
new
devices.
That's
basically
it
well
also.
Also
the
the
concept
of
master,
key
and
and
device
key
and
session
key
is
still
the
same.
Basically,
the
master
key
is
composed
by
a
two-layer
p.
Alright,
the
device
key
still
exists
in
the
concept
of
the
IDM
and
so
on.
It's
not
mixed
with
what
we
are
discussing
here.
A
A
That's
why
I
asked
about
the
performance
of
you
know
fetching
operations
because
it
might
influence
the
solution.
So
if
it
takes
like
four
minutes
to
read
records
from
from
I
know
that
has
and
didn't
and
woke
up
yet
it's
basically,
it
basically
makes
me
this
side.
Okay,
we're
not
gonna.
Do
this
ship
well.
C
A
Know
and
then
we
have
a
solution
tree
which
honestly
I
didn't
quite
understand
the
solution
there.
It
was
proposed
by
a
team
but
but
I
mean
I
really
did
like
a
few
times
already
and
and
I
couldn't
really
understand
what
he,
what
he
mean,
a
means
with
the
custom,
validator
and
so
on.
So
perhaps,
if
you
could
help
me
out
understand
what
what
we
try,
what
he's
trying
to
express
there?
It
will
be
awesome.
A
A
B
B
B
C
C
A
A
A
A
So
in
terms
of
the
the
whole
topic
was
to
decide
on
the
first
year
method,
and
we
already
discussed
on
a
few
problems
of
IP,
ID
and-
and
there
is
also
another
possibility
which
is
important
in
box
tack.
I
wouldn't
go
for
block
stack
because,
while
they
are
well
while
they
are
taking
technically
using
the
ID
methods
or
sorry,
they
are
technically
technically
at
the
ID
method.
They
don't
really
come.
A
On
the
contrary,
Newport's
has
a
core
library.
That's
basically,
they
use
in
their
mobile
app
and
other
scenarios,
so
usually
have
all
the
tools
to
create
your
port
identities
and
many
played
tennis
as
we
see
fit,
and
so
we
still,
we
still
be
facing
those
those
two
scenarios,
like
you,
port
or
IP,
ID.
A
B
C
B
B
C
Sure
it
depends
a
bit
on
the
use
case
right
because,
like
for
example
Bitcoin,
you
know
if
you
lose
your
key,
you
just
lost
you
know
a
million
dollars
or
in
my
case
ten
dollars,
but
people
will
sort
of
learn
to
accept
that,
for
that
particular
use
case.
So
maybe
it's
okay
to
develop
that
as
as
a
starting
point,
if
it's
simple
just
this,
for
that
particular
use
case
where
there's
no
key
replication
or
anything
and
then
to
create
more
complex
kinds
of
identity.
Further
down
the
line,
I.
B
Agree
if
we,
if
we
could,
if,
if
you
could
layer
identities
like
like,
like
you,
have
the
device,
identity
and
I
know
that
you've
been
thinking
a
lot
about
this,
so
device
keys
and
then
session
keys
and
then
the
master
key
on
top
of
those.
But
if
you
could
layer
in
terms
of
their
the
software
architecture,
you
could
layer
like
there
is
device
keys,
and
that
has
its
own
happiness.
If
you
lose
it
you're
the
device
is
compromised
and
later,
if
you
want
to
like,
have
a
master
identity
that
brings
those
together.
A
By
doing
the
solution
1,
we
aren't
really
saying
that
we
are
gonna
have
solution
to
in
the
future,
because
those
are
our
evolving
specs
and
we
can
have
virtually
of
the
specs
so
essentially
the
the
spec
of
the
IP
IP
ID
can
evolve
and
the
software
the
code
itself
can
in
may
and
should
handle
different
versions.
Let's
say
that
time
we
resolving
these
IP
ID.
This
is
the
ID
pointing
to
a
I
pay.
The
high
court
I've
been
a
cycle.
A
I
should
be
able
to
see
the
version
and
by
looking
at
the
version,
I
should
buy.
I
can
fork
connect
Forks
in
terms
of
code
to
handle
those
different
scenarios,
so
we
could
start
for
by
having
the
solution,
one
which
is
really
simple.
It
doesn't
have
many
many
of
the
issues
we're
gonna
discussing,
but
bear
in
mind
that
the
solution
1
has
some
implications
in
terms
of
the
Y
and
X,
because
having
any
new
device
is
really
cumbersome.
A
B
Now,
what
what
I
was
saying
is,
that
is
that
yeah
I
understand,
but
a
new
device
would
be
in
you
and
Yuki
and
you
identity.
No,
that's
not
not
great,
but
if
the
and
and
nothing
would
have
to
think
about
this
a
bit.
But
if
you
could
layer
make
it
so
that
it
doesn't
compromise
future
multi,
multi
level
device
solutions
like
first,
you
only
have
device
key
and
laterally.
B
B
A
So,
essentially,
if
I
carry
the
reification
list,
it
will
be
also
beheaded.
That
key
will
be
added
to
that.
That
list
and
all
the
signatures
made
prior
to
that
moment
are
valid
and
all
the
signatures
made
afterwards
will
be
invalid
or
discarded
and
also
alter.
The
idea
of
that
happens
with
the
P
that
was
revoked
will
be,
will
fail.
Basically,
so
it's
not
really
complex.
It's
just
that
the
multi
writer
scenario,
and
also
the
master
key,
is
necessary
for
this
operation.
A
Basically,
whenever
you
need
to
mu
take
the
document
you
need
to,
you
need
the
master
key.
That's
the
thing,
but
with
some
clever
tricks
like
the
layer
two
or
the
two
layers
approach
for
the
misaki,
the
master
key
can
be
disseminated
to
the
throttle
devices,
because
you
really
have
last
resorts
private
key
to
revoke
all
the
others.
Basically,.
B
B
C
B
A
A
Just
whenever
you
add
a
new
device
or
revoke
any
device-
and
maybe
if
you
later
change-
let's
say
cafe-
alike
or
identity-
have
a
like
service
that
you
want
to
associate
to
your
identity.
You
may
also
need
your
master
key
so
that
your
daddy
document
has
a
property
called
services
that
points
that
has
an
entry
there,
pointing
to
your
cafe
alike
or
identity,
have,
like
instance,
God.
A
A
A
B
One
is
not
too
bad
the
multi-multi
writer
I
guess,
since
the
spec
doesn't
require
you
to
store
the
plain
text
of
the
Jenny
document.
If
you
could
start
a
disparity
that
can
later
be
merge
at
the
edges,
I
think
that
problem
can
be
mitigated,
because
what
you
would
end
up
is
like
if
a
device
is
offline,
some
changes
are
made
when
it
comes
offline.
Some
concurrent
changes
can
be
happening,
but
he
will
detect
that
it
will
merge.
B
A
B
A
I,
probably
will
be
the
solution
that
we
will
use
and
also
we
can
leverage
simpler
solution
to
the
connectivity
things
such
thing,
because
whenever
you,
you
update
your
approval
device,
one
like
that
and
you
are
all
fine,
we
can
leverage
some
UI
language.
Saying:
hey.
You
didn't
synchronize
your
this
device.
Somehow
you
need
to
be
online
for
it
to
synchronize
something.
A
The
replication
you'll
need
that
for
the
identity
profile,
then
that's
something
that
we'll
be
discussing
on
Friday,
but
essentially
all
the
identity
profile,
your
name,
your
photo
and
all
the
information
they
personal
information
that
you
have,
including
your
social
proof,
will
be
have
to
have
to
be
synchronized
and
replicated.
So
whenever
you
set
up
a
new
device
and
attack
like
six
of
the
twelve
words
and
you
you
know,
have
a
new
device
working
on,
you
need
to
replicate
that
stuff
net.
That
is
a
process
that
we
must.
B
A
A
Me
too,
so
outcome
of
this
is
meeting
first,
we
need
to
probably
discuss
using
CR
et.
Oh
sorry,
probably
we're
gonna
use
gr
DET
to
solve
the
multi
writer
scenario.
I
will
discuss
if
we
need
of
you're
gonna
use
periods
are
similar
to
that,
and
also
the
CR
DT
itself,
like
the
merging
resolution
is
what
was
really
gonna,
be
stored
on
the
D
on
the
leg
nodes,
either
the
full
document
or
just
adds,
and
then
we
have
a
resolving
part
and
for
in
terms
of
them
there's
the
solutions.
A
B
A
Right,
that's
enough
for
me,
because
I
know
can
focus
on
the
solution,
one
and
both
in
terms
of
code
and
also
user
experience
and
from
the
multi
write
a
scenario
I
will
think
about.
How
can
you
use
this
realities
and
also
how
the
state
will
be
stored
on
the
deck
nodes
if
it's
the
full
Jason
or
if
just
the
operations
and
anyway,
I
will
come
up
with
something
wrong
on
get
up
and
we'll
discuss?
These
seem
to
a
synchronized
with
yeah.
B
A
A
For
forget
that
snare
for
this,
because
you
know,
whenever
you
add
a
device,
you
need
to
store
the
list
of
devices
somewhere,
because
whenever
you
go
to
another
device
and
your
buddies
boots
up
and
synchronizes,
you
will
see
the
same.
Two
devices
listed
listed
there
in
both
devices.
It's
correct
and
you
never
everyone.
All
the
devices
won't
see
that
new
device,
it
should
feel
real
time
and
and
which
will
have
a
replication
protocol,
and
this
is
the
same
for
that.
It's
the
profile
whenever
you
read
it,
something
like
your
name
and
so
on.
A
B
B
A
By
the
way
out
alternate,
alternatively,
you
may
use,
we
may
use
an
our
BTB
there's
a
that's
another
stuff
using
P
of
X.
We
just
need
to
discuss
on
that.
I
will
comment
on
you
know
about
this,
and
perhaps
you
can
converge
on
the
specific
CR
DT
and
a
notification
protocol
solution
specific
solution
either
peer
buyers
are
already
or
some
minutes
also
all
right.
Thank
you
very
much
for
coming
and
see
you
soon.
She
said
about
the
video
I
want
me
to
publish
yeah.