►
From YouTube: Reimagining Trusted Interactions
Description
Wayne Chang of Spruce Systems, joined us to present how Spruce Systems is reimagining trusted interactions through the creation of new identity infrastructure with Kepler.
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
Kepler
is
a
decentralized
storage
network
organized
around
data,
overlays
called
orbits,
and
it's
built
using
ipfs.
It
supports
many
different
kinds
of
storage
back-ends
and
the
goals
of
it
are
to
provide
permissioning.
For
example.
How
do
you
delete
stuff
from
ipfs
today?
There's
probably
a
lot
of
answers
that
we
can
figure
out,
but
we
want
to
figure
out
a
pretty
canonical
way
to
control
that
for
people
who
do
need
to
delete
things
to
comply
with
things
like
gdpr
or
the
ccpa
here
in
the
states.
So
that
means
we
need
some
kind
of
permissioning.
A
Ideally
if
it's
key
based
and
also
capability
space
and
I'll
get
into
that
in
a
bit
and
the
ability
to
talk
about
where
you
actually
want
the
data
to
live
right.
What,
if
you
have
ipfs
nodes
everywhere?
How
do
we
constrain
it
to
a
single
country
or
a
single
building?
Maybe
your
basement,
you
know
how
do
we
make
sure
your
iot
data
can
kind
of
stay
in
your
house
and
not
get
eaten
up
by
a
cloud
provider
or
something
like
that
right?
A
So,
what's
an
orbit
well,
an
orbit
is
something
that's
a
data
overlay
defined
by
an
orbit
manifest
resolved
by
what
we
call
an
orbit
identifier,
so
they
can
live
in
a
bunch
of
places.
We
like
smart
contracts
because
it
actually
solves
a
lot
of
the
problems
such
as,
if
you're
setting
permissioning
who's
the
orbit
commander
who's
in
charge.
Here
they
can
set,
who
can
read
and
write
it,
and
you
can
actually
just
use
the
smart
contract
itself
to
get
the
access
to
changing
the
base.
A
Permissions
updatable
dhts,
as
we
see
ipfs
and
ipfs
log
from
the
orbitdb
project,
not
really
it's
kind
of
related
to
kepler
orbits,
but
a
different
project.
I
spoke
to
the
orbit,
dv
team
and
you
know,
thankfully
it
seems
that
they're
not
too
upset
that
we
decided
to
call
capital
orbits
orbits,
but
they
are
different,
but
orbit
manifest
live
there.
They
could
live
as
ceramic
documents.
Textile
instances
even
carry
event
logs
in
the
decentralized
identity
community.
A
There's
something
called
carry
the
key
event
received
infrastructure
that
can
also
serve
this
purpose.
The
idea
is
that
we
have
a
new
url,
where
the
hosts
are
actually
defined
in
a
smart
contract
controlled
by
the
user.
So
you
truly
own
your
data
in
that
you
can
direct
people
where
to
find
the
hosts
authorized
to
host
your
data,
and
then
we
use
content
identifiers,
as
you
might
expect
in
ipfs.
A
So
this
way
and
there's
some
other
information
too,
that
define
aspects
of
the
orbit
such
as.
What's
the
base
permission
model,
as
I
mentioned,
when
we
issue
capabilities,
what's
the
valid
validity
status
there,
either
a
certificate
revocation
list
or
a
cryptographic
accumulator
can
be
used
and
then
content
state.
What's
the
latest
merkle
root
hash
of
content?
What's
our
consistency
strategy
and
what
are
the
authentication
methods?
We
support?
Here's
some
example
of
identifiers
this
might
this
one
is
based
on
the
tesla's
blockchain
has
an
account
has
a
predefined
host.
A
You
can
have
implicit
parameters
as
part
of
the
orbit
identifier,
so
you
don't
even
have
to
deploy
a
smart
contract
if
to
be
able
to
have
some
strict
defaults.
You
can
also
use
a
smart
contract
and
just
source
it
from
there.
That's
fine
too,
and
then,
in
order
to
turn
a
kepler
identifier
to
a
kepler
url,
you
either
put
the
identifier
as
is,
or
you
hash
it,
and
then
you
can
refer
to
the
content
identifier.
A
A
This
is
an
example
of
some
of
the
data
that
you
might
find
in
the
orbit,
manifest
that
you
resolve
from
your
favorite
blockchain
from
ceramic
from
textile.
Any
of
these
services
that
support
this
kind
of
document,
update
methodology,
so
you
might
find
out
who
the
orbit
commanders
are.
Who
is
really
in
charge
of
all
the
stuff
who
can
read
and
write?
Who
can
delegate
those
permissions
as
capabilities
and
who
can
manage
the
host
list?
A
The
host
list
in
orbit
manifest
can
have
a
list
of
a
public
key
derived
identifier
to
ip
addresses
or
even
an
onion
address
content.
Hash
can
be
the
merkle
root
and
we
might
have
a
revocation
state.
We
need
to
maintain
what
capabilities
we've
issued
are
valid
or
not,
and
we
might
have
consistency
strategies.
Let's
say
you
don't
want
to
wait
for
mercury
update.
You
want
a
faster
system
running
on
top
of
it,
maybe
byzantine
fault,
tolerant
across
all
the
hosts
in
the
orbit,
well,
that
it
can
be
specified.
A
Also
with
the
policy
we
separate
content
and
policy
policy
changes
being.
If
you
want
a
lot
of
readers
or
something
you
don't
want
to
store
them
all
in
the
manifest,
because
it's
expensive
to
store
in
a
layer
one
block
chain.
You
know
you
might
want
a
different
consistency
strategy
for
that
data.
We
try
to
separate
policy
and
content.
We
also
have
different
authentication
methods,
including
w3c,
verifiable
presentations
and
blockchain
specific
ones.
We
also
want
to
support
a
bunch
of
other
authentication
methods
from
web,
authentic,
blockchain
wallet
signing
so
anything
anytime.
A
You
can
sign
something
with
a
blockchain
wallet
that
should
you
can
build
an
authentication
method
out
of
that
ssh
off
and
gbt
keys
are
good
and
even
looking
at
some
enterprise
people
who
want
x,
509
family
of
things
in
mutual
tls
being
able
to
configure
these
per
orbit.
So
it's
really
tailored
to
the
use
case.
A
What's
the
capability,
it's
the
ability
to
do
something
like
right
to
an
orbit
up
to
500
megabytes.
Maybe
someone
wants
to
give
you
file
they're,
like
how
do
I
give
it
to
you?
You
can
give
them
a
capability
and
they
can
write
to
your
orbit
within
the
scope
of
that
capability
being
able
to
read
or
write
a
specific
content
hash
to
an
orbit
or
delegate
an
ability
to
someone
else
to
be
able
to
do
that.
A
So
we
wanted
capabilities
to
be
pretty.
We
wanted
them
to
be
secure.
We
wanted
them
to
be
expressive
and
we
wanted
them
to
be
pretty
useful
to
people.
So
we
have
something
called
cryptoscript
that
we're
working
on.
That
is
a
statically
typed
non-turing,
complete
dsl.
We
don't
like
turn
completeness
when
we're
just
trying
to
describe
things-
and
you
know
the
bitcoin
authors
and
a
bunch
of
other
folks
who
use
reduced
languages
for
security
purposes
and
simplicity,
that
we
took
inspiration
from
them
but
being
able
to
check.
A
Let's
say
an
nft's
owner
on
the
blockchain,
make
sure
that
it
matches
with
the
person
authenticating
with
request
and
then
only
letting
the
nft
owner
download
the
content
for
that
nft
right.
That's
the
kind
of
permissioning
expression
that
we
want
to
be
able
to
have
here.
So
what
does
cryptoscope
look
like?
A
Well,
we
have
some
primitives.
Let's
say
that
we
want
to
convert
a
p256
k1
pub
key
to
a
bitcoin
address.
There's
a
pretty
deterministic
way
to
do
this,
that
a
lot
of
people
already
know
but
being
able
to
express
it
clearly
and
then
make
sure
that
it's
not
an
attorney
complete
language
makes
it
a
lot
easier
to
formally
verify
if
you
want
to
or
even
compile
to
an
implementation
in
a
different
language
such
as
cryptal
or
rust,
or
whatever
you
like.
A
So
you'd
be
able
to
push
things
onto
the
stack,
take
the
hashes
duplicate
things
as
necessary.
This
is
a
fourth
inspired
stack
based
language,
but
it's
not
determined
if
it
needs
to
be
stacked
based
or
not
take
a
certain
number
of
bytes
concatenate
stuff
and
encode
it
with
base
58
check.
That's
how
you
get
a
bitcoin
address
from
a
public
key
of
this
type,
tesos
and
ethereum,
pretty
similar
even
simpler
for
tezos.
You
might
want
to
take
the
blade2b
hash.
A
Well,
you
have
to
with
digest
size
of
20
of
the
ed25519
key
for
tc1,
and
then
you
encode
it
as
basis
58
check
for
ethereum.
You
would
basically
take
the
hash
of
the
sec
p256k
one
pub
key
and
you
drop
the
first
12
bytes,
and
then
you
encode
it
in
base
58
check,
see
we
we're
basically
describing
how
to
get
from
point
a
to
b
in
a
very
crisp
and
unambiguous
way,
when
you're
trying
to
actually
write
c
and
like
work
with
pointers
or
borrow
checkers
and
rust
like
it
can
get
a
little
hairy
there.
A
So
having
this
pure
expression
of
it
is,
I
think,
a
very
useful
way
to
represent
it,
but
you
can
also
kind
of
talk
to
the
outside
world.
In
the
world
of
decentralized
identity,
we
have
something
called
the
didweb
did
method,
and
this
this
is
a
form
of
decentralized
identifier
resolution
where
you
just
query
a
website
over
tls
and
you
can
implement
that
actually
with
cryptoscript.
If
you
have
a
few
libraries
that
understand
http
clients,
you
might
be
able
to
push
the
expected
path,
pass.
A
The
method
specific
identifier,
concatenate,
the
two
strings
resolve
it
https
and
presumably
the
did
module
would
provide
a
validation
function
for
you
to
check.
If
that
json
you
fetched
was
a
valid
document
or
not,
and
to
the
example
I
gave
before,
if
you're
trying
to
check
the
nft
owner
to
make
sure
that
they're,
indeed
you
know
the
nft
owner
before
you
give
them
access
to
this
really
adorable
cat
picture
or
something
that's
large.
A
The
original
you
might
have
instructions
specific
to
those
assets
that
consume
the
asset,
address
and
asset
identifier
pushes
an
address
onto
the
stack.
If
and
only
if
successful,
and
then
you
might
take
the
vp
signer,
the
verifiable
presentation
signer
convert
that
to
a
public
key
hash
address
for
blockchain
and
then
assert
equivalents
between
the
two
addresses
on
the
stack.
And
if
you
clear
it,
you
can
give
access.
A
But
if
you
don't
clear,
then
you
throw
an
exception
and
it's
denied
and
you
might
even
want
to
explain
to
people
why
you
denied
them
so
we're
taking
a
lot
of
bitcoin
and
blockchain
inspired
technology
based
on
the
lock
unlock
functionality
and
turning
it
into
something
that
can
cross
multiple,
blockchains
and
cryptographic
systems,
so
that
we
can
specify
very
clearly.
You
know
what
it
is,
we're
trying
to
check
here
and
then.
Finally,
in
the
future,
we
imagine
these
orbit
relationships
where
you
can
store
a
bunch
of
things
into
orbits.
A
This
is
really
inspired
by
bs
freebsd's
geo.
There's
a
brilliant
article
there
that
I
can
share
the
zoom
after.
But
if
we
have
two
orbits,
what
if
we
could
have
such
a
copy
and
write
relationship
between
orbit,
one
and
two,
where
you
only
have
read
access
to
orbit
one
and
you
want
to
be
able
to
write
to
it
somehow,
so
you
make
an
orbit
three
that's
copy
and
write
one
and
two
and
all
your
changes
are
stored
to
orbit
two
orbit.
A
A
You
might
even
have
a
copy
and
write
over
that
set
that
you
just
made
in
orbit
six.
You
might
have
a
specific
content
hash
that
you
pin
the
order
that
and
you
want
to
copy
and
write
against
that
with
this
new
orbit,
7,
where
you
would
store
all
your
changes
and
then
finally,
we
really
just
rely
on
content
object
stores.
We
don't
actually
have
a
concept
of
metadata
like
s3.
A
Does
you
can
update
s3
metadata
in
the
headers,
for
example,
so
for
content
metadata
here
you
might
be
able
to
specify
a
metadata
companion
orbit
like
this,
and
it
would
store
the
metadata
there.
You
could
build
an
index
over
the
both
orbits
and
have
some
kind
of
key
value
functionality
like
s3
and
then.
Finally,
if
we
have
orbit
with
streaming
objects,
maybe
by
default
streaming
objects
are
very
bare
in
kepler,
where
you
just
receive
exactly
once
delivery
and
what?
A
So
that's
a
bit
about
orbits.
So
far
we
this
project
didn't
exist
like
a
month
or
two
ago,
and
we've
made
a
lot
of
headway
since
and
it's
built
in
rost
on
top
of
ipfs
in
bed.
Thank
you,
ipfs
embed
team.
It's
been
great
to
use
that
as
the
modular
toolkit
ipfs
rs
also
looks
great
too,
and
they
seem
very
compatible.
So
I'm
impressed
at
that
and
then
basically
oops.
A
A
Basically,
what
would
look
like
with
ipfs
log
or
a
upgradable,
dht,
multiple
authentication
method,
so
you
can
use
the
ub
key
and
then
being
able
to
implement
cryptoscript
and
these
orbit
relationships
we're
talking
about.
So
that's
what
we're
working
on
for
the
rest
of
the
year.
One
example
we
have
live
right
now
is
tesla's
profiles,
long
story
short:
you
get
verifiable
credentials
that
ties
your
twitter
account
to
your
tesla's
address.
Where
do
you
store
this
credential
right?
A
A
So
that's
basically
all
I
have
to
share
about
orbitz
right
now
and
I
thank
you
for
listening.
We
have
a
github,
it's
open
source,
apache
2..
If
you
want
to
hear
more
about
how
the
products
architectured,
you
can
read
the
code
or
we
have
architecture
and
product
requirements
documents
in
the
repo.
If
you
want
to
hear
about
how
it's
built
or
the
problem
space
we're
trying
to
solve
and
always
love
to
chat
about,
kepler
decentralized
identity.