►
From YouTube: RETMKT Builders - Smart Records
Description
Petar presents on Smart Records at the Retrieval Market Builders Mini-Summit in April 2021.
A
Okay,
so
I'm
going
to
talk
about
smart
records,
which
is
basically
a
part
of
the
larger
theme
of
composable
routing,
and
the
status
of
this
project
is
that
we
have
a
actually
an
end
to
end
v0
committed.
Then
it's
working,
but
we're
not
just
at
the
point
where
you
guys
can
start
dog
fooding
it
it's
coming
it's
coming
soon,
probably
a
couple
of
weeks
or
so
first
thing
is.
I
just
want
to
give
you
a
broader
view
how
this
fits
in
the
larger
composable
routing
picture.
A
So
composable
routing
is
this
effort,
which
juan
alluded
to
essentially
trying
to
make
all
the
parts
of
the
end-to-end
content,
routing
very
reusable
with
each
other,
so
composable,
which
basically
means
making
them
individually.
Generic
smart
records
are
the
data
sort
of
half
of
the
composable
routing
and
the
other
half
is?
Is
the
logic
of
composable
routing,
so
we're
going
to
focus
on
smart
records
here.
Just
for
your
context,
though,
so
what
is?
What
is
this
routing
behavior
that
I'm
referring
to?
This
is
the
other
side
of
composable
routing.
A
It
basically
includes
three
things
which
are
how
you
write:
links
that
point
to
content
so
sort
of
rich
links,
not
just
cids,
which
are
just
opaque
and
have
no
hints
in
them.
So
how
do
you
write
links?
How
do
you
define?
How
do
you
describe
context
at
any
every
given
peer,
because
every
peer
has
their
own
circumstances
where
they
live
in
the
network,
and
this
is
their
context.
A
A
The
thing
that
makes
this
a
framework
is
that
routing
logic,
in
other
words,
what
you
end
up
doing
to
actually
find
the
content
is
a
function
of
the
link,
the
context
and
the
records,
and
the
function
is
fixed,
which
is
what
this
is.
What
makes
it
a
framework
we're
just
going
to
talk
about
smart
records
today,
okay,
so
roughly,
so
what?
A
So
now
this
is
a
mouthful
and
it
sounds
fairly.
Generic,
so
putting
some
flesh
to
it
is
is
just
interpreting
this
statement
in
the
context
of
the
familiar
dht
that
we
currently
have
so
so
what's
happening
in
the
dht
right
now
is
that
we
have
the
dht
actually
does
the
dht
protocol,
like
literally
in
the
ipfs
stack
it
actually
takes
care
of
two
jobs
at
once.
A
So
the
first
thing
that
we're
saying
here
is
that
the
putting
and
getting
of
data
should
be
decoupled
from
the
dht.
The
dht
should
only
be
doing
finding
of
peers,
so
that's
sort
of
step
step
one,
whereas
the
functionality
of
actually
storing
data
shared
by
multiple
protocols
is
this
new
project
that
we're
discussing
now
called
like
smart
records
and
it's
it
should
be
a
separate
protocol
that
just
happens
to
run
side
by
side
on
every
ipfs
node,
together
with
the
dht.
A
A
Because
this
kind
of
a
shared
data
space
does
not
only
necessarily
live
in
the
dht,
which
is
the
most
obvious
motivating
example,
but
you
could
also
imagine
sort
of
sending
these
records
across
completely
different
kinds
of
protocols
and
in
fact,
currently,
even
in
this
session,
but
also
in
in
w3d
work
group.
People
are
already
trying
to
send
records
records
through
pub
7
other
protocols.
A
A
A
The
key
point
here
is
that
the
data
associated
with
the
record
we
want
to
view
it
as
a
replicated
state
machine
which
has
its
own
interface
and
and
virtual
machine,
so
hence
it's
portable
and
the
key
requirements.
So
the
key
benefits
that
we're
going
to
get
from
it
is
that
it
supports,
like
I
said,
reading,
writing
merging
and
some
smart
services
that
I'll
mention
at
the
end.
Now
I
want
to
talk
next
about
the
use
cases
that
it
immediately
enables.
A
The
first
thing
is
it:
it
enables
the
deployment
of
new
applications
to
the
ipfs
network
without
upgrading
the
network.
So
if
somebody
writes
a
chat
application,
for
example,
where
the
participants
want
to
exchange
chat
specific
data,
they
can
store
this
in
the
dht,
because
the
dht
now
will
allow
you
to
kind
of
use
your
custom
data
structures,
not
just
the
hard
baked
ones.
A
It's
also
another
design
goal
here
is
to
enable
different
protocols
to
interact
with
each
other.
That's
why
records
are
a
public
blackboard
where
it's
one
blackboard.
So
there's
one
document
per
key
where
multiple
protocols
can
write
to
it
in
sort
of
their
own
spaces
and
therefore
they
they
are
able
to
sort
of
read
each
other's
data
if
they
understand
it
and
and
sort
of
benefit,
each
other.
Something
that's
not
really
possible
today.
A
Some
other
use
cases
are.
They
also
might
end
up
being
useful
for
facilitating
cryptograph
cryptographic,
protocols
that
require
a
third
party
and
I
say,
trusted
in
quotes
because,
depending
on
the
setting,
you
may
or
may
not
trust
a
dht
node
to
be
a
fair
sort
of
judge
between
two
other
nodes.
But
it
has
the
possible
potential
to
be
used
in
this
case,
as
well
as
a
some
kind
of
an
opportunistic
judge
which,
which
enables
lots
of
cryptographic
protocols.
A
I've
only
listed
fair
exchange
here
and,
generally
speaking,
something
that
I'm
very
excited
about
sort
of
a
side
benefit.
Is
it
actually
unlocks
application
development
on
the
dht
to
the
public
kind
of
unconditionally,
and
this
can
produce
lots
of
interesting
outcomes
it
should
when
we
release
it.
So
let
me
get
to
the
technical
aspect
of
this
thing
and
basically
kind
of
discuss
our
thought
process
approach,
sort
of
leading
to
the
to
the
design
that
we
currently
have.
So
the
key.
A
The
key
thing
to
just
remember
this
is
just
sort
of
coming
use.
The
dht
as
your
mental
model,
and
the
key
thing
is
that
there
are
multiple
hosts
of
the
data
that
is
being
stored
for
a
key.
You
know
this
because
this
is
how
the
dht
works.
So
there
are
multiple
writers,
so
many
people,
for
instance,
write
provider
records
for
the
same
key
and
they're
multiple
readers,
because
many
people
might
be
interested
in
the
same
key.
A
So
the
players
are
multiple
of
of
each,
and
these
are
the
the
hard
technical
requirements
that
this
shared
medium
has
to
have.
So,
first
of
all,
the
data
model
is
generic
because
it
has
to
be
generic,
because
we
want
different
protocols
to
be
able
to
use
it
so
think,
json
or
ipod,
in
fact,
they're
the
same
thing.
So
the
ipod
data
model
is
the
same
thing
as
json,
so
the
data
model
is
json,
roughly
sort
of
bottom
line.
A
The
updates
to
to
these
records
have
to
be
commutative.
This
is
simply
because
the
whole
system
is
asynchronous,
so
any
two
updates
can
be
reordered
and
the
semantics
of
what's
what's
happened:
shouldn't
change
the
values,
so
these
json
values
that
are
attached
to
keys
have
to
support
merging,
because
that's
because
the
the
value
of
a
record
is
is
virtually
always
distributed
across
a
few
different
dht
nodes
in
the
dht
setting
and
so
reconstructing
the
record
really
involves
collecting
all
of
them
and
merging
them
together.
A
So
merging
has
to
be
supported
and
merging
must
commute
with
updating,
for
the
same
reason,
asynchrony
and
the
final-
and
this
is
the
sort
of
like
the
the
the
crux
one-
is
that
conflicts,
which
can
only
happen
during
merging
and
updating,
must
always
be
resolvable,
because
that's
a
public,
medium
there's.
They
always
have
to
be
resolvable
right.
So,
and
this
is
designing
this
part,
this
is
sort
of
like
what
I
want
to
spend
a
few
slides
later
on
now.
A
Another
aspect
I
want
to
point
out
is
that
it
is
pretty
clear
that
sort
of
a
public
medium
like
this
requires
the
regulation,
meaning
what
I
mean
so
regulation
generally,
but
specifically
the
most
natural
kind
of
regulation
is
to
say
anytime.
Somebody
is
updating
a
piece
of
the
record.
We
would
expect
that
we
can
impose
payments
for
different
kind
of
aspects
of
the
of
the
operation
payments
per
for
per
size.
A
But
the
reason
why,
assuming
that
payments,
or
at
least
some
virtual
form
of
payments
are
are
are
part
of
the
system,
is,
is
kind
of
like
a
seems
like
a
straightforward
sort
of
thing
to
to
assume
is
because
it's
pretty
clear
that
if
you
can
just
publicly
write,
if
you
can
write
a
public
blackboard
for
free,
there
are
no
sort
of
well-behaved
ways
of
preventing
denial
of
service
attacks
other
than
payments.
Anything
else
would
essentially
be
compromising
with
the
clean
semantics
of
the
product
itself
of.
Like
writing
to
this
document.
A
I
know
some
folks
are
going
to
be
sort
of
concerned
about
well.
How
are
we
going
to
use
this
technology
in
the
ipfs
setting
where
there
are
no
payments
at
the
moment?
It's
not
a
problem
in
the
sense
that
you
could
use
these
records
without
a
payment
scheme
and
just
reuse.
The
techniques
for
denial
of
service
that
are
currently
these
are
really
heuristics
for
the
now
service
which
are
currently
being
used
in
ipfs.
A
So
I'm
not
gonna
delve
into
this
and
next
so
I
I
wanna
talk
about
the
con,
so
this
is
how
did
we
sort
of
design
how
to
do
conflict
resolution
really
kind
of
like
the
semantic
aspect
of
this
service?
So,
first
stepping
back
for
a
second
there's.
There's
two
ex
there's
two
extreme
ways
you
can
approach
conflict
resolution
in
general,
so
one
is
the
destructive
approach,
in
which
case
you
essentially
define
some
form
of
competition
between
different
writers
to
a
location
in
the
document
and
the
winner
gets
to
override
the
loser.
A
A
It
takes
a
lot
of
space,
but
also
it's
kind
of
it's
very
difficult
for
what's
more
concerning
to
me,
is
it's
very
difficult
for
our
users,
which
is
application
developers,
so
users
of
smart
records
to
actually
deal
with
with
a
data
structure?
That
is
a
sequence
of
updates
because
they
have
to
worry
about
sort
of
reconciling
them
and
merging
them
themselves.
A
A
The
there
is
a
the
good
news
is
that
there's
a
middle
ground
which
gets
actually
the
best
of
both
worlds,
so
the
middle
ground
is
simply
to
to
allow
so
to
basically
keep
a
a
separate
copy
for
every
writer,
so
a
separate
copy
of
the
of
the
record
for
every
writer,
and
this
makes
sure
that
writers
cannot
dos
each
other.
So
they
cannot
write
over
other
writers
data,
but
when
they
update
their
own
records,
they
can
overwrite
to
gain
efficiency
and
the
pros
and
cons
of
the
middle
approach.
A
So,
first
of
all,
the
good
news
is
that
if
you
have
the
middle
approach
as
your
as
your
basic
api,
you
can
implement
any
any
of
the
other
approaches
like
the
competition
based,
for
instance,
you
can
implement
it
at
the
application
layer
now.
One
downside
is
that
slightly
more
data
resides
on
the
record
host
because
you
have
a
copy.
You
have
a
copy
of
the
document
for
every
writer.
Of
course,
you
only
have
a
copy
of
what
they
have
written,
what
they
have
written
to
the
document.
A
I
don't.
I
think
this
is
a
fair
price
to
pay,
also
considering
the
fact
that,
if
you
believe
in
having
a
payment
model
for
all
the
rights,
the
host
of
the
records
not
only
doesn't
mind
people
writing
a
lot.
In
fact,
they
probably
prefer
that
in
order
to
make
money
and
of
course
the
on
the
other
hand,
the
middle
ground
approach
actually
uses
consider
considerably
less
data
than
the
extreme
non-destructive
approach.
A
A
I
already
said
these
peers
can
overwrite
their
own
documents
and,
and
the
last
piece
is
that,
every
time
a
peer
writes
up
sort
of
sort
of
updates,
a
piece
of
the
document
they
get
to
specify
a
ttl
for
every
single
node
in
the
document
that
that
they
write
this.
This,
of
course,
is
obviously
to
accommodate
protocols
that
have
different
temporal
semantics
of
of
how
they
want
the
data
to
to
stay
the
actual
interface
of
the
of
the
product.
A
These
things
by
the
way
are
easily
mergeable
from
a
developer
point
of
view,
unlike
getting
a
list
of
updates,
because
each
individual
peers
record
is
is
is
should
be
a
semantically,
correct
document
with
respect
to
the
protocol.
That's
not
true.
If
you
were
sending
individual
updates
to
the
reader,
why
do
we
need
to
send
the
peer
sequence
number?