►
From YouTube: An introduction to the Dag-jose project with Alex Good
Description
Alex Good stopped by to talk about an effort championed by Textile, 3box, and Protocol Labs: the Dag-jose project to create an IPLD codec for authenticated or encrypted data.
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
A
I'm
going
to
talk
about
the
the
dag
jose
project,
which
is
something
I've
been
working
on.
For
the
past
couple
of
weeks,
I've
been
funded
by
protocol
agent
ethereum
and
been
working
with
the
folks
at
textile
and
three
books
to
get
this
done
so
dag
jose
stands
for
what
dag
as
in
ipld
and
then
jose
is
json,
object,
signing
and
encryption.
So
it's
a
hard
j,
but
everyone
seems
to
say
jose.
So
that's
that's
how
I
pronounce
it.
A
So
what?
What
is
diagnosis?
What's
the
problem
it's
trying
to
solve?
I'm
gonna
introduce
that
and
then
I'm
gonna
talk
a
little
bit
about
how
we
solve
that
problem
and
then
specifically
about
the
go
api
and
then,
if
we
have
time
I'll
talk
about
the
implementation
and
go
so
some
of
this
will
be
quite
technical.
I
hope
it's
still
interesting.
So
the
way
I
see
it,
ipld
and
ipfs
more
generally
are
about
data
interoperability
and
one
of
the
problems
that
we
run
into
with
public
data.
A
So
the
ipfs
network
is
generally
public
is
that
we
want
to
sign
or
encrypt
data
and
at
the
moment
every
application
ends
up.
Writing
their
own
little
mini
format
to
describe
how
the
data
was
authenticated
or
encrypted,
and
that
reduces
the
interoperability
of
it.
It
makes
it
harder
to
write
code.
That's
generic
over
how
something
was
authenticated
or
encrypted
so
diagrams
say,
is
an
attempt
to
solve
that
problem.
It's
an
interoperability
standard
for
for
authenticated,
encrypted
data,
jose
itself
is
actually
an
existing
standard
for
authenticated
and
encrypted
data
on
the
web.
A
It's
basically
a
standard
json
representation
for
authentication,
encryption
and
there's
two
generally
speaking,
two
objects
that
we
care
about:
json
web
signatures
or
jws
and
json
web
encryption,
which
is
jwe
web
developers,
will
often
actually
encounter
these
in
the
form
of
json
web
tokens,
which
are
a
form
of
jws
used
for
authenticating
against
web
apis.
So
there's
an
existing
ecosystem
of
libraries
that
handle
these
things.
A
A
So
you've
got
the
signature
itself,
which
is
just
a
device
to
the
signature,
and
then
you
have
some
elements:
the
header
and
protected
header
which
effectively
represent
metadata
about
that
signature,
which
implementations
can
use
to
figure
out
how
the
signature
was
made
and
to
verify
it.
So
that's
that's
authenticated
data
and
then
for
encrypted
data.
Very
similarly,
you
have
a
set
of
defined
keys
and
then
you
have.
A
The
key
part
of
this
is
the
ciphertext,
which
is
the
whatever
encrypted
data
you
have,
and
then
recipients
is
a
series
of
specific
to
each
recipient
data
which
can
be
used
to
decrypt
the
data.
So
in
both
cases
the
the
details
of
the
actual
shape
of
these
objects
is
not
necessarily
that
important.
For
this
talk,
the
main
thing
is
that
there
is
a
standard
format
for
how
these
objects
are
laid
out
and
it
has
to
will
be
url,
safe
json.
A
So
everything
is
base64,
url
encoded
and
these
are
generally
pretty
well
supported.
There's
also
different
serializations
of
these.
So
these
two
forms
here
are
called
the
general
serialization
there's
a
flat
and
serialization
where
you
can.
If
you
only
have
one
recipient
here,
for
example,
or
if
you
only
have
one
signature
in
a
jws,
you
can
hoist
the
keys
of
the
signature
of
the
recipient
now
into
the
top
level
and
then
there's
a
compact
serialization
which
is
designed
for
use
in
urls.
But
we
don't
particularly
care
about
those.
A
We
can
encode
the
general
serialization
fairly
efficiently
because
we're
using
cbor
instead
of
json
and
we
can
losslessly
convert
to
and
from
in
the
library.
So
we
just
use
the
general
civilization.
So
I
guess
the
the
first
question
here
is:
how
do
we
actually
represent
these
jose
objects
in
ipld?
And
this
is
there's
a
spec
for
this?
That's
the
link.
I've
just
posted
there,
but
it's
fairly
straightforward.
Really.
A
We
have
a
multi-codec
which
indicates
that
a
cid
refers
to
some
jose
data
and
then
to
actually
encode
a
jose
object,
either
jws
or
jwe
into
into
iprd.
We
we
just
encode
it
in
siebel
rather
than
json,
and
because
we
have
a
byte
type
in
cbor,
we
directly
use
that
rather
than
base64
url
encoding
any
payload
data.
And
then
we
add
these
two
extra
requirements
which
I'll
talk
about
a
little
bit
in
a
minute,
which
is
that
if
it's
a
jws,
the
payload
is
the
bytes
of
a
cid.
A
And
if
it's
a
jwe,
the
ciphertext
is
decrypts,
the
bytes
of
the
cid,
which
seems
like
an
odd
requirement
and
I'll
get
back
to
it.
But
just
to
make
that
concrete.
If
we're
to
look
at
this
jws
to
encode
this
in
iprb,
we
encode
it
in
cbor
everywhere
you
see
base64
url.
You
can
basically
replace
that
bytes.
A
So
one
of
the
things
that
almost
any
spec
that
deals
with
encryption
or
authentication
will
do
is
define
some
kind
of
canonical
way
of
encoding
json
or
whatever
your
data
structure
is
so
that
verifiers
can
reproduce
it
in
the
same
way
as
the
signer,
so
that
they
can.
They
can
verify
the
data
structure,
and
this
is
quite
complicated,
but
we
can
kind
of
avoid
doing
that
because
we
already
have
ipld
as
a
way
of
encoding
arbitrary
data.
So
we
just
use
that
and
also
applications.
A
A
If
you're.
If
this
plain
text
is
a
cid,
then
that
seems
like
it
would
mean
that
you're
putting
the
the
plain
text
on
the
network
somewhere
and
all
your
encrypting
is
is
the
hash
of
it,
but
we
can
use
the
identity
multicast
to
avoid
this
problem.
So
what
that
means
is,
if
you
have
a
cid
which
uses
the
identity
multi-hash,
then
what
that
means
is
that
the
bytes
of
the
object
that
the
cid
refers
to
are:
actually
we
don't
hash
them
at
all.
A
So
that's
kind
of
an
overview
of
of
how
we
of
what
the
spec
says
about
how
we
encode
this
work.
What
I've
been
working
on
is
ago
implementation
of
this,
so
you
can
be
found
on
this
link
and
I
think,
there's
also
a
link
in
chat
yep.
All
this
library
handles
is
serialization
to
and
from
json
and
to
and
from
ipld
there
are
other
libraries
which
are
really
quite
mature,
which
can
be
handled
can
be
used
to
handle
crypto.
A
So
the
main
thing
this
is
just
concerned
with
is
just
a
very
simple
api
to
convert
to
and
from
json
ipod.
So
here's
what
reading
a
jws
looks
like,
so
we
create
a
cid.
This
is
using
the
go
ipod,
prime
library,
which
is
a
I
think,
reasonably
new
library,
for
interacting
with
ipld
data
in
go
so
we
created
cid.
We
assume
that
there's
already
some
data
on
the
network
that
the
cid
points
to
that
is
a
dag,
has
a
jws
object
and
then
the
interesting
piece
of
code.
A
I
guess
the
entry
point
of
this
library
in
the
middle
of
the
page
right
there
you
see
this
diagram.load
has
a
function.
So
the
first
argument
to
that
is
the
cid
that
we
just
created
the
two
context.
Arguments
are
not
particularly
interesting
for
this
and
then
the
the
fourth
argument
is
an
implementation
of
it.loader,
which
basically
is
anything
that
knows
how
to
get
data
from
ipfs,
and
this
is
this
is
something
that
anyone
using
the
ipl
prime
library
would
already
have
on
hand.
A
So
the
result
we
get
from
that
function
is
a
is
a
union
of
both
jws
and
jw
objects,
because
the
the
spec
doesn't
determine
doesn't
tell
us
what
kind
of
object
is
in
in
the
cid.
We
know
that
it's
either
a
jws
or
jwe,
so
we
then
have
this
as
jws
method,
which
will
return
not
nil.
If
the
the
object
is
a
jdbs
and
if,
if
it
isn't
jws
there's
another
one
called
as
jwe
and
then
at
the
bottom,
we
can
see
here
we're
just
printing
out
the
general
json
serialization
of
the
jws.
A
So
that's
where
your
integration
point
with
a
third-party
library
would
sit.
So
you
can.
You
can
then
pass
that
general
serialization
and
go
jose
or
you
can
pass
it
yourself
or
hand
it
off
to
any
other
third-party
services
that
can
handle
jws
objects
and
writing
looks
broadly
similar.
You
say:
you've
you've
signed
some
data
using
the
go
jose
library,
for
example,
and
you
have
you
then
have
the
general
json
serialization
of
that
jws.
A
A
A
So
that's
the
api
of
the
library
that
I've
been
working
on
it's
fairly
simple.
There
is
a
helper
library,
I'm
working
on
which
it
handles
things
like
encoding
things
in
an
identity,
multihash
and
various
utility
functions
to
do
with
encryption
decryption.
That
just
makes
the
user
experience
a
bit
easier,
and
I
was
hoping
to
get
onto
the
some
implementation
details,
but
it's
coming
up
to
quarter
two,
so
I
think
I'll
probably
stop
there.
A
Although
for
the
last
week
of
this,
I
guess
something,
that's
kind
of
fun
and
exciting,
I'm
working
on
is,
is
sort
of
tying
everything
together
and
making
sure
that
we
can
store
jose
objects
using
powergate
via
ceramic,
which
is
a
project.
Three
books
are
working
on
that
is
actually
using
the
stuff
in
anger
via
the
javascript.