►
Description
The Whiteboard Series with NEAR is a set of video interviews with Founders who are building scalable solutions for Blockchain. We deep dive into their story, what they're developing and how it is helping the ecosystem.
In this episode, our Co-Founder, Illia Polosukhin (https://twitter.com/ilblackdragon) interviews Joel Thorstensson (https://ceramic.network/) co-founder / CTO
of 3Box Labs (https://twitter.com/3boxlabs). Joel is a known entity in the Blockchain space.
Follow the latest from Ceramic on:
Website: https://ceramic.network/
Dev Docs: https://developers.ceramic.network/learn/welcome/
Discord: https://discord.com/invite/6VRZpGP
Follow the latest from NEAR Protocol on:
Website: https://near.org/
Dev Docs: https://docs.near.org/
See what's being built on NEAR: https://awesomenear.com/
Learn to Build On NEAR: https://www.near.university/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol
A
B
B
So
ceramic
is
a
protocol
for
mutable
data
objects
where
you
have
objects
that
live
under
the
centralized
network
and
they
have
like
a
controller,
some
user
that
can
change
and
mutate.
The
object
over
time.
Essentially
like
get
a
history
of
like
how
the
the
object
will
change
over
time
and
you
get
like
kind
of
like
an
immutable
kind
of
log
of
like
what
has
happened
and
these
objects
are
independently
verifiable.
B
E
B
B
Because
without
this,
you
need
kind
of
need
to
like
either
trust
completely
like
if
there's
timestamps,
if
the
user
puts
the
timestamp
in
there,
so
we
have
another
system
that
basically
creates
something
called
anchor
commits
or
anchor
events.
So
this
is,
you
can
call
it
a,
and
this
also
points
back
to
the
previous
one,
and
this
essentially
contains
some
meta
data
information.
That's.
B
Chain
chain
id,
it
was
anchored
to
and
like
a
transaction
hash,
and
it
usually
so
so.
This
is
usually
done
by
some
kind
of
anchor
service
that
can
like
take
a
bunch
of
updates
to
a
bunch
of
different
streams,
generate
a
merkle
tree
and
put
the
root
on
chain.
So
usually
it
contains
like
a
merkel
witness
as
well.
B
B
You
know
the
sign,
commit
and
batches
a
bunch
of
those
into
a
merkle
tree
and
puts
the
root
on
chain,
and
then
it
kind
of
gives
back
this
anchor
commit
that
contains
like
this
was
anchored
on
this
chain
id
right
now,
it's
a
theory,
minute
transaction
hash
and
a
mark
like
a
path
through
the
to
the
merkle
tree
and
yeah,
and
then
like
you,
can
continue
updating
the
the
stream
like
this.
So
this
is
kind
of
the
data
structure
and
so
a
ceramic
node.
B
When
you
make
an
update
to
one
of
the
streams
you,
you
publish
an
update
in
elite
pdp
pub
sub
network
so
that
anyone
can
kind
of
that
is
interested
in
a
stream
can
like
update
and
sync
that
stream
and
yeah
that's.
Essentially
it
like
and,
and
then
like.
The
second
part
of
this
is
we
have
a
query
system
that
allows
you
to
if
you're
a
new
node
in
the
network,
you
want
to
sync
any
particular
stream.
B
E
B
Basically
put
say,
saying
a
node
that
pins
this
stream
basically
says
hey.
I
have
this
stream
id
put
it
in
the
dhc
and
then
put
there
there.
So
the
ipfs
dht
basically
works.
Like
you
know
you,
you
say
you
have
an
object
and
then
you
put
your
ip
address
or,
like
your
multi
address
into
the
dht,
so
we
can
basically
find
all
the
peers
that
pin
the
stream,
and
so
we
walk
the
dhc
and
to
find
all
the
peers
that
have
this
stream.
And
then
we
ask
them
like
hey.
B
E
B
D
B
But
ceramic
is,
is
primarily
aimed
at
like
user-centric
data.
So
if
you
do
this,
you
kind
of
do
this
and
then
later
reveal
kind
of
the
main
person
that's
like
affected
by
that,
because
this
this
stream
id
is
like
controlled
by
you
and
like
it's
controlled
by
your
identity,
you're,
basically
like
basically
revoking
things
you've
done,
and
it's
probably
mostly
harmful
to
you
and
your
reputation
as
you
built
up
on
this.
This
account.
B
A
A
B
B
If
we
were
to
go
with
this
branch,
someone
that
steals
key
those
like
in
in
the
start,
in
the
start,
they
could
potentially,
like
you
know,
create
a
new
update
in
the
future,
and
so
we
need
to
go
this
kind
of
earliest
anchor
rule
because
you
wrote
it
like
if
the
earliest
rotation
of
the
key
needs
to
be
the
one
that's
valid.
Otherwise,
the
the
key
rotation
part
wouldn't
be
secure.
C
F
A
A
B
A
B
So
right
now,
like
developers
in
their
application,
configure
which
node
that
they
use
so
right
now,
it's
kind
of
like
on
the
developer,
to
make
sure
that
you
know
they're
using
it
that
they
care
about
for
their
application
is
pinned
yeah.
So
that's
roughly,
it
is
like
right
now,
like
in
theory,
like
a
user,
could
spin
up
a
node
and
replicate
their
data.
D
B
A
A
A
D
A
B
B
Yeah
yeah,
so
it
could
be
like
it
can
be
like
we
support
internally,
we
have.
We
have
a
dnd
method,
called
380
and
that's
based
on
on
this,
but
we
also
support
other
dad
methods.
They're
like
based
on
ethereum
and
whatnot,
okay
yeah.
I
mean,
I
guess
so
in
general,
like
the
id
is
simply
like
yeah
perfect,
it's
a
little
bit
loose.
I
think.
F
B
B
B
F
E
F
D
B
No,
it
doesn't
have
actual
code,
that's
kind
of
like
an
annoying
thing.
This
this
you
can
specify
verification
methods
that
are
like
different
things,
so
you
have
to
for
each
kind
of
like
curve.
In
each
thing
you
have
to
have
like
a
specification
somewhere
yeah
and
it
needs
to
be
like
okay.
This
is
how
it's
verified,
so
that's
like
go
officially
like
it
needs
to
go
through
the
w3c
like
standard.
D
A
B
That's
right,
so
it
would
be
nice
if
there
was
like
an
abstract
way
to
just
like
find
a.
You
know,
see
a
d80
method
and
like
find
the
reference
implementation,
like
fetch
that
code
yeah,
there
are
some
projects
working
on
that
type
of
like
dynamic
code
loading,
but
none
are
like
super
solid.
Yet,
as
far
as
I
know,.
A
B
Yeah
definitely
yeah,
I
mean
it's
it's
easier
for
these
kind
of
things,
which
is
kind
of
like
static
yeah.
I
think
I
don't
know
like
so.
These
are
like
public
key
hashes,
but
I
guess
basically
based
on
like
this
is
a
hash
of
a
public
key.
So
you
don't
need
to
resolve
anything.
You
can
just
like
verify.
D
B
D
B
Yeah,
and
so
so,
there
are
like
standard
interfaces
for
like
resolving
at
the
id,
but
yeah
we
need
like.
It
would
be
ideal
if
we
could,
like
dynamically
resolve
these
types
of
things,
but
ultimately
it
kind
of
becomes
like
if
the
node
has
support
for
like
a
lot
of
dld
methods.
That
kind
of
puts
a
lot
of
like
external
dependencies,
in
terms
of
like
trust,.
D
B
Yeah,
so
I
guess
I
guess
it
would
be
interesting
to
talk
about
so
this
did
pkh
the
the
reason
we
are
interested
in
that
is
we're
building
an
object
capability
system
to
do
authentication
into
ceramic,
because
right
now
you
kind
of
like
need
some
kind
of
system
for
our
did.
You
know
if
it's
a
very
simple
case.
We
have
a
good
key.
E
B
Need
to
store
the
private
key
somewhere
yeah,
and
so
you
could
generate
a
private
key
forwarded
key
and
started
in
the
browser,
and
that's
fine
for,
like
short,
lived
things.
If
you
have
a
did
three
like,
we
want
to
keep
those
keys,
secure
and
right
now
we
have
a
system
that
involves
an
iframe
and
involves
like
signatures.
A
little
bit
like
involved
in
like
using
an
iframe,
is
obviously
like,
not
like
the
the
best
security.
C
B
B
B
B
B
D
B
B
B
D
D
D
A
B
So
so
in
this,
in
this
model,
you
have
like
this
access
list
of,
like
all
of
the
keys
yeah,
all
the
accounts
that
have
access
yeah,
whereas
in
here
we
don't
need
to
keep
the
state
anywhere.
This
dap
is
responsible
for
keeping
this
all
cap
around
and
only
like
displaying
it
once
once
it's
used
like
including
it
once
it's
used
yeah.
I.
D
B
D
B
And
that
could
be
like
you
know
in
in
theory,
you
could
make
all
caps
like
very
generic.
Like
general,
I
think
I
think
ocaps
is
actually
when
it
was
invented,
like
used
on
an
operating
system
level
where
having
these
kind
of
axis
control
list
is
like
really
expensive,
because
you,
you
kind
of
need
to
check
them
and
keep
track
of
them,
whereas
here
you've
kind
of,
like
only
have
this
object
where,
wherever
you
need
it
yeah,
I.
A
B
A
E
A
B
B
D
B
B
A
B
Yeah,
no,
we
don't.
We
don't
anchor
every
change
we
right
now
because
of
like
you
know:
ethereum
maintenance,
expensiveness.
We
occur
twice
a
day
and
obviously
that
needs
to
increase
as
it's
like
the
the
network
grows,
but
yeah
I
mean
yeah.
These
kind
of
transactions
here
are
kind
of
like
not
find
really
final.
Until
it's
been
activated.
E
B
To
this
actually
in
the
implementation,
we
don't
allow
you
to
rotate
keys
until
it's
been
anchored
and
then
you
can
go
through
again,
but
for
the
for
for
so
so
in
380,
we
kind
of
anchor
every
every
update,
but
in
like
generally
in
streams,
we
kind
of
like
make
a
bunch
of
updates
and
then
anchor
and
depending
on
how
much
it's
used.
Of
course,.
A
B
No,
it's
definitely
this
thing.
This
was
in
the
d80
core
specification,
but
the
ability
to
check
like
when
was
the
last
update,
and
when
is
the
next
update.
That
was
not
something
that
we
we
had
to
add
that
to
the
d80
core
and
we
barely
got
it
in
for
like
conversion.
Problems
like
this
is
a
bug
in
this
thing,
because
otherwise
it
doesn't
really
work
in
trustless
systems,
exactly
yeah
and
like
trustless
systems.
What's
that,
like
a
bunch
of
like
web
2
people
building
this
decentralized
identifier
spec?
B
E
A
B
B
We
have
implemented
an
experimental
feature
or
experimental
did
method
called
the
ide
nft
and
obviously
that
allows
you
to
like.
I
can
update
it.
Then
I
send
it
to
you
and
you
can
update
the
stream,
and
so
there,
this
kind
of
data
withholding
attack
that
we
talked
about
is
problematic
because
people
can
you
know
if
I
create
this
nft,
I
make
a
bunch
of
updates
and
like
now
you
see
like.
Oh
that's
super
cool
like
I
want
to
have
it
and
I
send
it
to
you,
then
I.
A
B
A
B
Yeah
I
mean,
I
guess,
like
an
ocap,
would
be
revoked
at
the
time
of
transfer
and
of
transfer.
But
anything
that
was
you
know
issued
before
and
like
used
before
would
still
be
valid
because
it
would
be
at
the
time
there's
like
a
lot
of
complications.
So
ideally
would
make
this
kind
of,
like
general,
to
any
blockchain.
B
So,
with
version
id
we're
actually
using
version
time
now
and
for
we
have
this
implemented
for
a
few
different
ethereum
chains,
and
it's
essentially
like
you
take
the
version
time,
you
use
the
graph
to
basically
look
up
what
the
state
of
that
who
the
owner
of
that
nfc
was
at
that
point
in
time,
yeah
so,
but
yeah.
So
for
this
type
of
of
thing,
the
the
streams
that
we
talked
about
isn't
really
kind
of
ideal.
B
And
so
this
is
one
of
the
reasons
we
want
to
introduce
like
a
a
blockchain
where
you
have
streams
represented
just
as
objects
on
chain.
You
can
still
have
this
kind
of
like
event,
log
that
happened,
yeah
and
kind
of
verify
the
history
independently
that
it's
actually
like
signed
by
the
right
user,
so
that
you
know
the
if
there's
like
an
attack
by
validators
or
whatever
they
can't
actually
like
fake,
which
transaction.
D
B
B
But
yeah
and
that
you
can-
and
we
still
want
to
keep
this
kind
of
property
of
like
every
stream
being
completely
independent,
so
you
so
you
can
kind
of
like
sync,
only
the
data
pieces
that
you're
interested
in
yeah,
like
I
don't
know
how
much
it
makes
sense
to
dive
into
that
right.
Now,
it's
like
very
early
in
in
kind
of
research
and
development,
yeah
yeah,
that's
kind
of
the
what
we're
going
for
there.
So
that
would
be
like
that.
B
Ideally,
it's
also
solving
a
different
problem
right,
also
because,
like
one
problem
with
this
right
now
is
that
you
have
to
run
your
own
ceramic
node
yeah
or
you
trust
the
third
party
to
run
a
node
for
most
users
are
not
going
to
do
that.
So
the
the
the
blockchain
could
potentially
also
provide
like
a
service
where
you
pay
and
actually.
B
B
B
E
B
B
B
B
B
B
E
B
D
A
B
D
A
A
A
B
B
A
B
The
like
the
merkley's
tree
is
like
very
useful
for
or
like
the
the
hamped
kind
of
like
symmetric
trees
are
useful
for
a
key
value
store.
But
if
you're
making
a
list,
you
probably
want
to
have
a
different
structure,
yeah
and
depending
on,
like
which
direction
and
which
way.
When
I
iterate
quickly
through
the
list.