►
From YouTube: Dynamic Content with resource updates
Description
In this presentation from Day 2 of the #SwarmOrangeSummit, Louis Holbrook continued with his second presentation at the Swarm Orange Summit with a presentation on titled mutable resources. In this presentation he shows how to link dynamic content to a constant Swarm address, which is an essential capability for creating decentralised systems on Swarm.
A
I
will
try
to
make
this
a
little
less
painful
than
the
last
time
in
the
sense
of
less
code
and
and
clutter,
and
the
theme
this
time
is
mutable
resources,
which
is
a
very
mystical
theme
of
which
you
only
heard
vague,
rumors,
I'm,
sure
and
I
will
try
to
give
an
overview
of
what
this
is.
With
the
help
of
my
favorite
mutants.
A
So
mutable
resources
are
a
predictable
way
of
looking
up
data
and
swarm.
Now
we
all
know
how
these
address
thing
works
actually
coming
to
think
of
it.
I
explained
exactly
the
same
thing
couple
of
hours
ago,
so
we
don't
really
need
to
go
through.
All
of
that,
we
know
that
when
you
have
some
data,
that
you
know
that
the
the
hash
of
that
data
will
become
the
address
of
the
data
that
you
want
to
put,
and
then
you
find
your
way
to
the
nearest
node
matching
that
data
and
it
ends
up
being
there.
A
So
we
know
where
to
look
for
it,
but
you
know
to
guess
what
this
data
is
gonna,
be.
It
was
kind
of
like
a
whack-a-mole
game.
It's
really
really
hard
to
do.
In
fact,
it's
so
hard
to
do
that.
You
would
have
approximately
this
number
of
moles.
What
you
can
fit
in
here,
and
probably
even
God,
would
have
a
hard
time
knowing
where
to
strike.
A
So
how
can
we
somehow
make
this
more
predictable?
Well,
we
all
know
that
we
have
something
called
with
just
the
right
slide.
Yeah
we
have
something
called
the
NS,
so
you
pay
for
putting
a
name
a
link
between
the
VC.
Remember,
you
used
to
remember
name
and
chunk
address,
but
of
course
this
is
expensive.
You
have
to
pay
every
time
and
it
also
tends
to
be
a
little
bit
slow,
since
the
average
block
time,
at
least
on
Robson
I,
think,
is
something
like
fourteen
point,
four
five,
seven
seconds
or
so
per
block.
A
So
wouldn't
it
be
nice
if
we
had
a
better
solution.
So
this
is
what
the
mutable
resource
is
about,
and
the
foundation
of
mutable
resources
is
kind
of
a
time
pulse.
So
it's
used
for
a
reference.
We
use
the
block
time
as
a
time
pulse
and
we
say
that
this
resource
we
will
update
every
so
and
so
many
blocks.
A
A
Then
we
could
say
the
next
block
in
the
period
if
we
have
one
block
every
four
blocks
or
every
one
update,
every
four
blocks
will
be
46,
so
we
go
look
for
an
update
at
block
number
46,
but
there's
nothing.
So
we
go
looking
in
the
past.
One
in
I
mean
the
one
before
that
in
the
frequency
that
we
have
set
the
block
update
rate
that
we've
set.
And
what
do
you
know
there?
A
Yeah
I
guess
I
should
probably
explains
what
these
blocks
are.
Maybe
or
yeah.
Would
this
be
easier?
Okay,
right,
yeah
all
the
Newtons
I
mean
it
should
be
self-explanatory
right.
So
what
we're
actually
doing?
So?
What
we're
actually
doing
is
we're
creating
fake
chunks
on
swarm,
so
all
the
chunks
that
are
unsworn
currently
our
content
addressed,
which
means
to
take
the
data
that
you
have
your
hash
it.
It
creates
a
deterministic
address
from
that
data
and
then
you
send
the
data
out
on
an
swarm
right.
So
you
know.
A
So
if
you
want
that
piece
of
data,
do
you
know
what
the
address
is?
It
will
be
exactly
that
piece
of
data,
but
this
is
unpredictable
right.
So
this
was
the
whole
whack-a-mole
thing
now,
if
we
let's
say
they,
we
have
a
scheme
where
we
know
exactly
if
I
put
this
data
together
with
this
data
and
hash,
that
I
can
send
and
can
say,
use
this
as
a
key
with
with
with
the
data
I
want
to
with
the
data
I
want
to
store
and
know
exactly
I
know
exactly
what
the
key
is
in
advance.
A
You
can
take
the
block
number.
Let's
say
a
constant
pulse
of
yeah,
in
this
case
the
block
number
and
a
version
number
and
creates
a
key
out
of
this,
and
then
you
use
this
as
the
key
to
store
on
on
on
swarm.
Instead,
so
let's
say,
I
want
so,
let's
say:
I
want
I,
have
this
period
of
every
four
blocks
right
I
know
that
the
starting
block
is
42.
A
A
Exactly
yeah
exactly
this,
so
the
reason
why
we
use
to
blocked
in
it
because
we
kind
of
have
to
have
a
similar
time
key
thing
between
all
the
notes.
So
if
you
use
the
sync
blockchain
for
this,
then
everybody
would
know
what
block
eight
we
are
in
and
thus
which
block
we
should
be
looking
for
next,
when
we
create
this
key
to
look.
Something
is
this
somehow
it's
just
somewhat
clearer,
yeah.
A
Right
so,
as
I
was
saying,
every
four
blocks
doesn't
sound
very
fast.
As
you
were
saying,
you
can
do
several
in
one
block.
So
that's
exactly
what
we
do
here
right
we
attach
to
this
one.
We
suddenly
have
free
updates,
which
kind
of
can
act
like
version
numbers
in
a
way.
So
now,
similarly,
we
were
block
57.
You
look
at
59.
There's
nothing
54,
there's
nothing!
50
we
find
something.
A
A
A
Okay,
so
yeah
I
need
to
say
that
so
initially
we
saw
that
the
start
block
is,
for
example,
here
42
right.
So
instead
of
keeping
these
awkward
numbers,
42,
46
and
whatever
it
is,
this
awkward
arbitrary
numbers.
Instead,
we
could
use
period
numbers
so
the
period
one
is
two
starting
blocks
and
two
will
be
the
next
one
in
frequency
and
so
on
and
so
forth.
So
when
you
choose
the
starting
block-
and
you
choose
a
frequency,
then
one
of
these,
then
you
can
actually
use
1
2
3
4
5
3.3
3.4.
A
Right
so
what
happens
when
you?
So
you
know
in
principle,
anybody
could
then
generate
a
resource
and
send
it
on
to
swarm
even
on
your
behalf.
Right
so,
let's
say
you
you
own
a
domain
called
mutable
F
and
you
start
having
a
Twitter
feed,
but
then
suddenly
somebody
else
comes
along
and
start
posting
to
mutable
F
as
well.
It's
not
so
cool.
Well,
it
depends
on
what
they
write,
but
if
they
write
something
nasty,
it's
not
so
nice.
A
So
that
is
why
all
the
updates
have
to
be
signed
first
of
all
and
signed
by
the
account
that
owns
the
e
NS
address
of
the
resource
that
were
updating
and
when
you
try
to
post.
This
will
be
checked
against
DNS
so
that
the
account
on
the
node
that
you
generate
the
update
from
will
be
chained
then
check
the
e
NS
ownership.
If
it
checks
out,
then
you
can,
then
you
can
send
the
resource.
A
Of
course,
you
can
always
hack
your
own
node
and
kind
of
circumvent
this,
but
other
nodes
in
the
network
will
check
this
relationship
as
well.
So
if
you
send
it
to
somebody,
they
will
check
it.
If
it's
fake,
then
they
will
drop
it.
So
it's
one
propagates
in
the
system
so
not
currently
implemented,
but
after
later
on,
they
will
also
be
issued
notification
messages
or
a
possibility
to
subscribe
to
messages
when,
when
updates
are
made
using
PSS
as
well
to
anybody
that
wants
to
listen.
A
Obviously,
if
it
doesn't
check
out
the
DNS
and
won't
be
sent
to
swarm,
as
you
see
here
and
no
updates
will
be
sent
so
shortly
or
a
short
overview
over
how
what
the
API
here
works
so
to
create
a
mutable
resource.
So
currently
only
HTTP
API
is
active
and
to
create
mutable
resource.
We
have
a
special
scheme
called
bzz
resource.
A
Id
would
be
your
ENS
name
that
you
want
to
latch
this
mutable
resource
onto,
and
the
frequency
would
be
the
pulse
of
the
update.
So,
as
we
saw
before
you
start
on
block
so-and-so
and
ever
before,
or
whatever
it's
the
frequency,
it
will
create
a
resource
on
the
starting
block
or
on
the
block
height
that
we're
currently
on.
So
that
will
be
now
to
update
a
resource
you
post
to
that
same
DNS,
name
with
whatever
data
that
you
want
to
post
to
retrieve
the
latest
update
that
you
did.
A
A
A
A
If
you
give
I
realize
I'm
sorry,
but
I
realized
that
these
slides
of
the
API
are
actually
old.
So
I
will
show
you
exactly
how
it
works
on
my
terminal
just
in
a
minute,
so
there
are
either
arbitrary
data
updates,
which
is
just
verbatim
raw
data
that
you
send,
or
you
can
send
swarm
hash,
in
which
case
the
backend
will
treat
it
as
a
hash.
And
if
you
issue
the
normal
BCC
retrieval
of
the
resource,
it
will
actually
show
you
the
page,
that's
behind
it.
A
So,
first
of
all,
we
kill
my
my
data
directory
so
that
there
is
nothing
there
and
then
we
start
our
swarm
node.
So
what
we're
doing
now
is
the
swarm
notice
started
up
and
it's
connecting
to
the
open
test
cluster
now
up
until
this
morning
it
was
not
a
problem
to
get
the
updates
to
show
under
test
cluster,
and
this
morning
it
was
lagging
very
far
behind.
So
probably
will
just
be
so
a
local
demonstration,
but
it's
still
it's
still.
Let's
try
so
to
create
resource.
We
do.
A
A
A
A
A
By
one
mutable
test,
how
we
see
we
get
list,
Whisperer
PSS
is
the
fubar
etc.
So
let's
get
the
first
one.
For
example,
we
see
when
we've
done
post
fix
this
with
first
period,
one
version
one.
Then
we
get
the
first
update
now
with
these
updates
that
we've
done,
we
haven't
updated
NS
right,
we've
only
sent
chunks
to
swarm,
but
we
can
still.
Where
did
that
window
go,
but
we
can
still
retrieve
it
through
any
NS
name.
So,
let's
go
to
the
other
update
version,
which
is
multi
hash
updates.
A
So
lie
one
mutable
test
now
yeah,
it's
saying:
won't
display
content-type
application/octet-stream,
because
the
updates
that
we
did
were
raw
and
when
you
do
raw
updates,
the
HTTP
requests
will
have
the
type
of
octet
stream.
But
if
we
do
multi
hash
updates,
we
really
be
able
to
see
the
page.
So
then
we
do
swarm
up
page
HTML.
So,
let's
see
what
page
HTML
is
well,
it's
not
much.
A
It's
background,
color,
it's
a
color
of
text
and
it's
a
little
bit
of
text
here
we
take
this
hash
and
we
send
an
update
request
to
that
and
now
the
page
content
and
I
can
see
it's
HTML
right
and
let's
go
to
a
URL
form
and
the
browser
that
we
kind
of
recognized
from
before
now
we
see
we
have
I
can
barely
see
it
here.
So
it
says:
localhost,
8,
5,000,
BC,
cy1,
mutable
test.
It
has
a
blue
background
and
has
white
font.
A
A
A
A
A
Ya
so
yeah
it
downloads
the
application/octet-stream
the
update
from
before.
So
it
gets
something
it
just
doesn't
get
the
latest
chunk.
So
I
know.
I
was
bragging
about
that.
This
is
kind
of
faster
than
us
and
stuff,
so
obviously
not
right,
but
when
the
sinker
will
work
properly
and
everything
is
up-to-date,
this
will
happen
all
at
the
speed
of
swarm
syncing.